GeoGateway Formats Reference

Version 9.1

PCI Geomatics

50 West Wilmot Street, Richmond Hill

Ontario, Canada

L4B 1M5

Phone: (905) 764-0614

Fax: (905) 764-9604

www.pcigeomatics.com

"Legal Notices"


Introduction

Generic Database (also known as GDB) is a technology allowing programs to access data in many geomatics file formats, in a uniform manner, without having to translate them before use in applications. GDB includes access to imagery, vectors, attributes, projections and other auxiliary information of interest to users of geomatics applications.

Each file format supported by GDB is implemented within the GeoGateway library. All data types, and access approaches from the generic Data Model that make sense are implemented in a seamless manner.

However, not all file formats support all datatypes, or access approaches. In fact currently only PCIDSK (the format on which the Data Model was modelled) supports all possible data types. It is therefore important to recognize that different formats have limitations. The "Supported File Formats" topics describe each of the supported file formats, and their limitations.


Greater than 2 GB File Support

For PCIDSK and other formats that support greater than 2 GB file sizes, the following restrictions apply:

  • On computers using the FAT32 file system, the maximum file size is 4 GB minus 2 bytes.
  • For NTFS, the maximum file size is 2^64 bytes (16 exabytes or 18,446,744,073,709,551,616 bytes).

Since Windows 95, Windows 98, and Windows ME users cannot partition drives with NTFS, these systems are restricted to file sizes of less than 4 GB using FAT32.

Windows NT 4.0 systems with FAT drives are restricted to 4 GB file sizes. (Windows NT does not support FAT32.) Under NTFS, Windows NT systems are restricted to a maximum file size of 8 GB, but Service Pack 4 or higher will boost this limit to 16 exabytes.


2 GB Maximum

The following systems cannot support files greater than 2 GB:

  • Drives formatted as FAT (FAT16) partitions
  • Some NFS network drives
  • Linux systems


GeoGateway Data Model

In order to better work with GeoGateway-based applications, it is helpful to understand the GeoGateway Data Model. The data model is a description of the datatypes supported by GeoGateway, their relations, and the implications.


A GeoGateway Database

Within GeoGateway there are frequent references to GeoGateway databases. In GeoGateway a database is a grouping of data layers, usually referring to the contents of a single file. It does not normally mean a database in the RDBMS sense, such as Oracle, Microsoft Access, or DBase.

For GeoGateway purposes we define a database as a grouping of data layers, and associated auxiliary information. Each GeoGateway database has a name, normally the name of the primary file defining the database. Given a database name from the user, GeoGateway applications can open the database, read and/or write a variety of data, and eventually close the database again.

A database can contain raster layers (channels), vector layers (or segments), lookup tables (LUTs), pseudocolour tables (PCTs), ground control points(GCPs), a projection definition, metadata, and a variety of other auxiliary information.

Each channel of raster data or segment is considered to be a Layer in GeoGateway. This includes things like GCP segments and LUTs, for which the name layer seems inappropriate. However, it does not include the projection definition (even though this is a segment in PCIDSK).


Raster Data (IMG)

A GeoGateway database can have zero or more raster (image) layers which are often referred to as channels or bands. A raster layer consists of a rectangular grid, or array, of digital numbers.

Each grid value (or pixel) has a value normally indicating its brightness when displayed. However, the values can also have other meanings beyond just radiometry. A thematic raster layer might have a particular set of raster values, each indicating a particular crop type, or forest type. A raster layer might also be a continuous field relating to temperature, proximity to a fire station, or probability of erosion. The raster layers themselves don't indicate what the meaning of the raster values is. This is indicated by the user, the application, or in some cases metadata associated with the raster layer.

Within GeoGateway all raster layers in a particular database must have the same size. Size is normally reported as width in pixels, and height in lines. Furthermore, all raster layers are presumed to correspond to the same real world region, which will be discussed further in the georeferencing section.

Each raster layer has a datatype. Currently there are four supported GeoGateway raster data types:

  • 8-bit unsigned (8U): This is the most common datatype. Each pixel is normally stored as one byte of data on disk, and can have an integer value from 0 to 255; .
  • 16-bit signed (16S): Each pixel is normally stored in two bytes of data on disk, and can have an integer value from -32737 to 32736.
  • 16-bit unsigned (16U): Each pixel is normally stored as two bytes of data on disk, and can have an integer value from 0 to 65536.
  • 32-bit real (32R): Each pixel is normally stored as four bytes of data on disk, and can have an IEEE floating point value between approximately 3.4 x 10^38 and -3.4 x 10^38.

There is another kind of raster layer in GeoGateway called a bitmap, or graphic mask. In effect this is a 1-bit raster layer, but it is handled separately for historical reasons; they are covered separately in a later topic.

Where file formats supported by GeoGateway contain data not of these four datatypes, they are normally mapped to the closest datatype. In some cases this leads to a loss of precision. For instance, with a file format that supports double precision (64-bit) floating point values, the values will be mapped to 32R with the corresponding loss of precision. A data type like 4-bit integers in TIFF are mapped to 8U with no loss of precision.

The raster layers, or channels are numbered starting at one. For instance, a 24-bit TIFF file is represented within GeoGateway as a three channel raster file with channel 1 corresponding to the red, channel 2 to the green and channel 3 to the blue.

Pixels within a raster are addressed by their pixel/line location within the raster. The top left corner is the origin, with the pixel values increasing to the right (X axis), and line values increasing downwards (Y axis). The top left pixel is known as pixel (1,1), and appears at offset (0,0) from the origin.

Some calculations operate at a subpixel level. For these purposes the top left corner of the top left pixel would be at (0.0,0.0) and the bottom right corner of the top left pixel is at (1.0,1.0). The centre of the top left pixel is at (0.5,0.5). The centre of the bottom right pixel of a 1000x1000 image would be at (999.5,999.5).


Image Metadata

The following metadata tags are predefined for raster layers:

  • DEFAULT_PCT_REF: Reference to the PCT segment to be used to display this image in pseudocolour mode. If this entry is present the image should default to being displayed in Pseudocolour mode. Layer reference syntax is described in the general metadata topic.
  • DEFAULT_LUT_REF: Reference to an LUT segment to use as a default enhancement when displaying this image. Layer reference syntax is described in the general metadata topic.
  • SCALING_MIN: Default value to use as a minimum for scaling this image channel to 8-bit for display purposes.
  • SCALING_MAX: Default value to use as a maximum for scaling this image channel to 8-bit for display purposes.
  • NO_DATA_VALUE: The image value that indicates no data is available.
  • ELEVATION_UNITS: This may be UNKNOWN (implicit default), FEET, or METRES. It is primarily intended for use with elevation channels, and should be UNKNOWN for non-elevation data.
  • Class_n_Name: Short name for a theme class in a raster with n being the class number. Preferably, this name should be less than 9 characters.
  • Class_n_Desc: Longer description for a class in a raster.
  • Class_n_Color: Colour with which a particular theme class should be displayed. The value is the colour encoding using the "(RGB:rrr ggg bbb)" convention seen in the PCLColor class. In the future other variations may also be supported.
  • ACQUISITION_DATE: This is the date and time that an image was acquire. The format of date is "(YYYY/MM/DD HH:MM:SS)"

See Also


Georeferencing

Georeferencing refers to how data in a GeoGateway file is related to positions in the real world, or to locations in other datasets.

The raster layers in a database, including bitmap segments, are considered to have a single shared georeferencing definition, sometimes referred to as a georeferencing segment. This definition contains the map units string, a transformation from pixel/line coordinates on the raster to georeferenced space, and optionally additional projection parameters related to the particular georeferencing system.

Many of the possible georeferencing map unit values are related to true projections such as Universal Transverse Mercator, or Lambert Conformal Conic. A fully defined projection contains enough information to relate a pixel in the file to a real world location on the Earth.

Other georeferencing systems are not sufficient to relate things to a real world location, but still provide a useful coordinate system. For instance, a database may just be georeferenced in METRES relative to some implied origin. This may be sufficient to relate different databases and perform calculations of area and perimeter, but are not sufficient to establish a location in the world.

A georeferenced image may be georeferenced to a proper projection or to an arbitrary coordinate system. Images can also be ungeoreferenced, which is treated by GeoGateway using the special coordinate system "PIXEL", with a unity transformation. The full list of georeferencing systems, including projections, can be found in the Projections documentation. This includes information about the set of projections and their associated parameters, and also discusses the topic of earth models and data.

The transformation between pixel/line coordinates and georeferenced coordinates is stored in terms of the top left corner of the image, and an x and y pixel size. This implies that raster pixels do not have to be square in georeferenced space. However, there is no concept of a rotational coefficient; therefore georeferenced images in a projection are always stored with north at the top.

When accessing georeferenced images that are not north up, GeoGateway must discard the georeferencing information. In some cases, the corner coordinates are represented as a ground control point segment, in order that the image may be warped to north-up representation, and then treated as a georeferenced database. It is intended that this restriction be relaxed in a future release of the GeoGateway library.

Vector layers and ground control point segments also contain projection definitions local to those layers. In these projection definitions there is no transform; however, the map units and projection parameters are kept, in order that the relation between the georeferenced coordinates of the points may be related to real world locations.


Segment Organization

Data other than raster imagery is often referred to as segment data, or as auxiliary segments. This relates back to the structure of the PCIDSK file; however, you can consider segments as being similar to layers or channels.

Unlike raster channels, auxiliary segments are not required to be numbered sequentially. For instance, in the irvine.pix PCIDSK file there are two PCT (PseudoColour Table) segments, numbered 7 and 8. In PCIDSK files the segment number, for a particular segment, is unique among all other segments in that PCIDSK file. This is not generally true in other formats; for instance, a bitonal TIFF file might have a PCT segment with the number 1, and a bitmap segment number 1.

Each type of segment has a three letter code associated with it. This three letter code is often included in reports and utility programs to show the type.

  • VEC: Vectors
  • BIT: Bitmap (1 bit raster)
  • GCP: Ground Control Points
  • LUT: Lookup Table
  • PCT: PseudoColour Table
  • TEX: ASCII Text


PseudoColour Tables (PCT)

The PCT segment contains a pseudocolour table. This is an array of 256 RGB colours used to assign colour values to 8-bit images. The PCT always contains exactly 256 entries, whether they are all needed or not. File formats such as TIFF which may have colour tables with less than 256 colours normally have the remainder of the colour table filled up with zeros (black).

There is no support for translucent or transparent entries in the table.


Lookup Tables (LUT)

The LUT segment contains a lookup table. Fundamentally this consists of 256 8-bit values, between 0 and 255. It is normally used to apply an enhancement to raster data; however, it can also be used to encode a thematic class remapping.


Ground Control Points (GCP)

A ground control point segment contains up to 256 ground control points. Ground control points are normally used to associate projection coordinates with locations on a raw (uncorrected) image; however, they can theoretically be used to relate locations in any two georeferencing systems.

Each ground control point defines a location in each of two georeferencing systems: the first georeferencing system (normally raw image coordinates), and the second georeferencing system (normally some projection system). The definitions of the georeferencing systems are kept as 16 character map units strings, with "PIXEL " indicating raw image coordinates.

Since projection parameters are not stored, only projections that are fully defined by the map units string, can be used (e.g., UTM, Long/Lat, or METRE). Complex projections such as Transverse Mercator cannot be used. It is hoped that this limitation will be relaxed in the future.

Each of the control points can also have an elevation associated with the location in each image. An elevation unit string is kept for each system; it may have the values of "METRE" (the default) or "FEET".

Each ground control point has the following values associated with it:

  • Id: A unique numeric identifier for the control point. If it is negative, it is interpreted as indicating that the point is a check point, and should not contribute to the transformation model.
  • System 1 X: The X coordinate in the first georeferencing system. This is normally a pixel location in the image.
  • System 1 Y: The Y coordinate in the first georeferencing system. This is normally a line location in the image.
  • System 1 Elevation: The elevation of the location in the first georeferencing system. This is normally zero, and ignored by applications.
  • System 2 X: The X coordinate in the second georeferencing system. This is normally a location in projection coordinates.
  • System 2 Y: The Y coordinate in the second georeferencing system. This is normally a location in projection coordinates.
  • System 2 Elevation: The elevation in the second georeferencing system. This should be zero if it is not used.

There is currently no way of storing more than 256 GCPs, nor of associating symbolic names with the control points.


Bitmap Masks (BIT)

A bitmap segment is a special raster layer with each pixel having either the value of 0 or 1. They are normally used as masks for an area of operation, for instance: training areas in classification.

Bitmaps are rectangular raster grids, much like image layers, and must have the same number of pixels and lines as any other raster layer in the database. The georeferencing associated with the raster layers is also assumed to apply to bitmap layers.


Vectors (VEC)

Vector layers, or vector segments, are used to hold a set of related vectors. Vectors can be points, polylines (arcs), whole polygons, topological polygons, or objects without vertices which are really just database records.

Each vector object in GeoGateway is called a Shape. Each Shape has a numeric identifier called a ShapeId that is unique within the layer, and is greater than or equal to zero. While the ShapeIds are normally assigned sequentially starting at zero, it is possible to have a layer with holes between ShapeIds.

Each Shape has a record of attributes associated with it. The attributes are stored in the layer, and are considered to be part of the shape. Each shape also has a list of zero or more vertices. Within GeoGateway the vertices are represented using double precision IEEE floating point numbers; each vertex has an X, Y, and Z value. The vertices are presumed to be coordinates in the georeferencing system of the vectors.


Attributes

Each shape in a vector layer has a record of attribute data associated with it. There can be zero or more attributes; however, all the shapes in one layer must have the same set of attribute fields.

In database applications, the set of fields or columns, their types, their names, and any other descriptive information is often called a Schema. Fields can be one of five types:

  • Float/Double: The field is a floating point number. Float and Double are similar, except that double precision fields have more precision than float fields. The actual storage precision will depend on the format.
  • Integer: The field is an integral number.
  • String: The field is a variable length string. Many formats (i.e., .dbf) only have fixed length string fields, in which case, the formatting information will indicate the length of the field.
  • CountedInt: The field contains a list of numbers. This is typically used to maintain lists of related shapes (e.g., ArcIdList in a topological area layer, or RingStart for multi-ring polygons).

Many databases have additional field types that are either mapped onto GeoGateway field types or ignored (dates are usually treated as an integer or a string).

Each field has a field name associated with it. There are no fixed length restrictions on the name, but it is intended to be short, and will be used as a column header in many applications.

Each field has a format specification, which indicates the number of characters that should be used for the field when it is displayed in reports or dialogues. It also indicates whether the field should be left or right justified. For the cases of Float and Double variables, it indicates how many decimal places of precision should be shown. This value is a clue to applications, and does not have to be used. For some formats the length and precision fields imply actual limitations of the underlying format, while for others it is just a convenience for display purposes.

Each field also has a default value. When not otherwise established, it is zero for numeric values, an empty string for string values, and an empty list for CountedInt lists.


Rings

Polygonal regions can be represented several different ways in GeoGateway. The simplest of which is closed polylines, that is, a vector for which the last vertex is the same as the first. These are sometimes called simple whole polygons.

In order to represent polygons with holes (doughnuts), or regions that consist of multiple islands, there exists a concept of multiple ring polygons. A multiple ring polygon essentially consists of a series of whole polygons, each of which is called a ring.

If one ring is contained in another, then it represents an internal boundary. The area that is part of the polygon is the area between the outer and inner ring. If the rings are independent, then they represent different islands, all of which are considered to be the same region. Multi-ring polygons are not polygons in the geometric sense, but they do represent regions, whether continuous (connected) or not.

Multi-ring polygons are represented in GeoGateway as regular shapes, with the vertices of all the rings all aggregated in the vertex list. The boundary between different rings is establish by entries in a field called RingStart. This is basically a list of vertex numbers, each of which is the first in a new ring. There is no entry for vertex 1 which is implicitly the start of the first ring.

For example:

Imagine the following scenario: Two islands (1) and (4), with island (1) having two holes (2) and (3), and island (4) having one hole (5).

 (1)                     (4)
 +-------------+         +------+
 | (2)  (3)    |         | (5)  |
 | +-+  +----+ |         | +-+  |
 | | |  |    | |         | | |  |
 | +-+  |    | |         | +-+  |
 |      +----+ |         +------+
 |             |
 +-------------+

This would be represented as one shape with 25 vertices and a RingList attribute of { 5, 10, 15, 20 }, with the vertex list consisting of the points of rings 1, 2, 3, 4, and 5. There is no expected order of rings, therefore holes can appear before the outer ring defining an area.

Note: Vertex numbers are considered to start from zero for the purposes of the RingStart variable, therefore ring (1) consists of vertices 0 - 4, and vertex 5 is the first vertex of ring (2).

When drawn by ring-aware applications, the line segment connecting one ring to the next is not drawn. In the above case, no line would be drawn between vertex 4 and 5.

For shapes with the RingStart attribute, it is not a strict requirement that the so called rings represent closed polygons. If a ring is not closed it does not represent a region boundary, but it is still drawn with the same disconnection logic as a closed ring. Thus, the concept of rings can be overloaded to represent a series of spatially disconnected polylines that share a common attribute record. This concept may be used in the case of interrupted streets, for instance.


Topology

The model of topology that has been implemented is the traditional node/arc/area approach.

  • Areas are bounded by a list of arcs.
  • Areas can have internal holes that also have arc boundaries. The holes are known as rings.
  • Arcs consist of a series of vertices, and start and end at nodes.
  • Arcs never intersect or overlap, but do meet at their endpoints (at nodes).
  • Nodes are points at which two or more arcs end (or start).
  • Nodes, arcs, and areas all have independent attributes.
  • Each Arc borders on, at most two areas, one on its left and one on its right.
  • Arc direction is significant, therefore one end node is designated the start node, and another the end node.

We keep track of the following as attributes of the nodes, arcs, and areas within GeoGateway:

  • For each arc: the ShapeId of a start node and end node.
  • For each arc: the ShapeId of a left area (or -1), and the ShapeId of a right area (or -1).
  • For each node: the list of ShapeIds of all arcs entering/leaving the node, in clockwise order (this can be derived from the arc information).
  • For each area: the list of ShapeIds of all arcs bounding the area in clockwise order, with an indication of whether the arc needs to be transversed forward or backward in order to proceed in a clockwise direction (this can be derived from the arc information).

A full topology consists of three vector layers (segments). These are: a node layer with the points of intersection of arcs, an arc layer with the lines defining boundaries between areas, and an area layer representing the polygon regions.

A key difficulty then, is to keep the three layers together, or at least to ensure that they can be found when necessary. This is dealt with through the use of inter layer references stored as metadata, on each layer in the topology grouping.


Topological Arc Layers

In addition to the topological metadata information, a Topological arc layer must contain the following attributes:

  • StartNodeId: Attribute containing the GDBShapeId of the starting node.
  • EndNodeId: Attribute containing the GDBShapeId of the ending node for this arc.
  • LeftAreaId: Attribute containing the GDBShapeId of the left area polygon, or GDBNullShapeId if there isn't such an area.
  • RightAreaId: Attribute containing the GDBShapeId of the right area polygon, or GDBNullShapeId if there isn't such an area.

An arc must have at least 2 vertices.

An arc layer must have NODE_REF, and AREA_REF metadata pointing to the related node, and area layers. It must also have a LAYER_TYPE of TOPO_ARCS indicator in metadata.


Topological Node Layers

In addition to the topological metadata information, a topological node layer must have the following attribute:

ArcIdList: (GDBFieldTypeCountedInt) List of arc ShapeIds starting or ending at this node.

Each node should also have one vertex defining the position of the node.

A node layer must have ARC_REF, and AREA_REF metadata pointing to the related arc, and area layers. It must also have a LAYER_TYPE of TOPO_NODES indicator in metadata.


Topological Area Layers

In addition to the topological metadata information, a topological area layer must have the following attribute:

ArcIdList: (GDBFieldTypeCountedInt) List of arc ShapeIds forming the border of this area in clockwise order. Each ring is separated by a GDBNullShapeId entry in the ArcIdList.

A topological area shape should have either zero or one vertex. If it has one, it will be presumed to be an internal label point for the area.

An area layer must have NODE_REF, and ARC_REF metadata pointing to the related node and arc layers. It must also have a LAYER_TYPE of TOPO_AREAS indicator in metadata.


Representation Style Table

The Representation Style Table (RST) is the way in which the graphical display of vectors is described, and stored. A vector layer optionally contains an RST, which, if it exists can be assumed to describe how shapes in that layer should be drawn.

An RST consists of zero or more representations. Each included representation is indicated by its representation code, or RepCode. This is the integer value used to look up the representation in the RST, typically based on the RepCode attribute of the shapes in the layer.

The representation consists of a series of zero or more parts. Each part describes a drawing method used when drawing a shape. Normally there is only one part.

Each part has the following information:

Priority: The priority is used to indicate how different vector drawing components should be layered. The higher priority values are drawn over those with lower priorities. This applies between different parts within a given representation, but also applies between different shapes drawn within a given layer, and in some applications is evaluated between all vector layers in a given view.

Graphical Primitive: The drawing primitive to be used for this part. Supported primitives include:

  • Simple-Line
  • Dash-Line
  • Spaced-Symbol
  • Simple-Point
  • Point-Symbol
  • Vector-Text
  • Solid-Polygon
  • Patterned-Fill
  • Transparent-Polygon

Parameters: Each primitive has a particular set of parameters affecting the display. For instance, the parameters of the Simple-Line primitive are width and colour.


Vector Projections

A vector layer includes a projection definition, indicating how the vector coordinates should be interpreted in world coordinates. This can be different from the projection for any raster layers, or other vector layers in the same database.

The projection definition can be for any projection. Unlike the GCP segment, there is no limitation to projections that can be defined with a map units string.

Unlike the raster projection definition, the vector projection definition does not contain any concept of a transformation between pixel/line and georeferenced coordinates.


Vector Metadata

The following metadata items have special meaning for vector layers:

  • LAYER_TYPE: Can be "UNKNOWN" (implicit default), "WHOLE_POLYGONS" (all shapes are closed polygons representing a region, possibly including internal rings, "TOPO_ARGS" (topological arcs layer), "TOPO_NODES" (topological nodes layer, "TOPO_AREAS" (topological areas layer), "POINTS" (all shapes are one vertex points), ARCS (all shapes are multi-point arcs) or "TABLE" (no vertices, this layer is pure attribute information). See the Topology definition for more details on the requirements of topological layers.
  • ARC_REF, NODE_REF and AREA_REF: A set of topological layers are grouped with each other with these metadata entries. A detailed explanation of the layer reference naming convention can be found in the general metadata topic.
  • XXX_FieldID: This metadata identifies what attribute field on this layer should be used for a particular renamable system attribute role. See the System Attributes topic for a list of system attributes, and their roles. The value can be the name of a field or its zero based field number. For example a REPCode_FieldID value of Attribute would indicate that the field named Attribute should be used as the REPCode for this layer.
  • LONG_FIELD_NAME_n: Long name for the indicated field. The long name is preferable for user display to the builtin short field name.

See Also

System Attributes, Topology


System Attributes

In GeoGateway it can be helpful to identify what attribute is to be used for special roles. There are many system attribute roles; however, it is likely that only some, or none of them will actually be associated with a real attribute within the file. In this case that role will be ignored, or take on a default value.

Renamable Attributes:

  • REPCode: The REPCode system attribute determines what field will be used as the index into the RST (Representation Style Table) when the layer is being rendered in WYSIWYG mode. This field must be of type integer.
  • GroupId: Within the ACE product, it is possible to use an attribute to relate shapes that are considered to be grouped. All shapes with the same group id value are considered to be related, and depending on the mode are moved and manipulated together. This field must be of type integer.
  • ChildList: This is an obsolete method of keeping track of internal rings of a polygon, and is discouraged at this time in favour of the "RingStart" attributes use.
  • Text: This points to the attribute to be used as the text for the purposes of rendering shapes as text, for instance when using the Vector-Text primitive in an RST. This attribute must be of type String.
  • Angle: This points to the attribute to be used as the angle of rotation for the purposes of rendering primitives that can render on an angle (such as Vector-Text, and Point-Symbol). Note that the Angle is normally expressed in radians, not degrees, so PI (3.14927) radians is 180 degrees. This attribute may be of type integer, float, or double.
  • XCoord: This attribute is used as the X coordinate to synthesise a single vertex for this shape. This is useful to work with tables where two columns define the X, and Y, and to have the X, and Y attribute columns be treated as a spatial position.
  • YCoord: This attribute is used as the Y coordinate to synthesise a single vertex for this shape. This is useful to work with tables where two columns define the X, and Y, and to have the X, and Y attribute columns be treated as a spatial position.
  • Height: This attribute is used as the Z coordinate to synthesise a single vertex for this shape. This is useful to work with tables where two columns define the X, and Y, and to have the X, and Y attribute columns be treated as a spatial position.

Fixed Name Attributes:

The following attributes are required to have fixed names, and can't be overridden with the XXX_FieldID metadata.

  • RingStart: This attribute that can be used to identify the portions of the current shape that are additional rings. This is more full described in the Rings topic. This attribute must be of type CountedInt.
  • ArcIdList: List of arc ShapeIds forming the border of this area in clockwise order. Each ring is separated by a GDBNullShapeId (-1) entry in the ArcIdList. This attribute must appear on layers with a LAYER_TYPE of TOPO_AREAS. This attribute must be of type CountedInt.
  • StartNodeId: Attribute containing the GDBShapeId of the starting node. This attribute should be present on all layers of type TOPO_ARCS. This attribute should be of type integer.
  • EndNodeId: Attribute containing the GDBShapeId of the ending node for this arc. This attribute should be present on all layers of type TOPO_ARCS. This attribute should be of type integer.
  • LeftAreaId: Attribute containing the GDBShapeId of the left area polygon, or GDBNullShapeId (-1) if there isn't such an area. This attribute should be present on all layers of type TOPO_ARCS. This attribute should be of type integer.
  • RightAreaId: Attribute containing the GDBShapeId of the right area polygon, or GDBNullShapeId (-1) if there isn't such an area. This attribute should be present on all layers of type TOPO_ARCS. This attribute should be of type integer.
  • ArcIdList: List of arc ShapeIds starting or ending at this node. All layers of LAYER_TYPE TOPO_NODES should have this attribute. This attribute must be of type CountedInt.

See Also

Representation Style Table, Topology


Descriptors And History

Each layer in a GeoGateway database can have a description string and a series of history records. The description string is one line, with at most 80 characters. Many formats cannot support this, in which case, attempts to modify the description have no effect, and the descriptor string is generated synthetically (e.g., "Vector layer %d").

Likewise, each layer can have a list of history records indicating operations that have occurred to the data. Well behaved GeoGateway applications will write a new record of history information when a data layer is updated.


Metadata

Each layer in a GeoGateway database can have metadata associated with it. Metadata is a set of string name/value pairs. An example is the NO_DATA_VALUE metadata field for raster channels. If this metadata is provided, the name or tag is NO_DATA_VALUE, and the value will be treated as a special raster image value, which is a no-data or missing data value.

There are a variety of predefined metadata tags with special meanings, but there is no system-imposed restriction on what metadata tags can be used. In essence, metadata is a way of associating application or translator defined information with data layers, without requiring that the whole GeoGateway system or all GeoGateway applications be aware of issues relating to that metadata.

Details of predefined metadata items for different layers are described in the definitions of those layers above.

Major current uses of metadata are for associating pointers to related topological vector layers, and for indicating display information (preferred scaling, LUTs, and PCTs) with raster layers.

These include a special class of "layer reference" metadata tags. Any tag ending in _REF is treated as being in the layer reference format. A layer reference is a special format for referring to other layers in the same or different GeoGateway databases.


Layer References

A REF string, is a string intended to encode enough information to find a particular data layer, with the assumption that it may be interpreted as being relative to a particular base file not shown in the string.

First, some examples to help get the flavour of the REF strings:

  gdb:/pci/src/gen/irvine.pix/{IMG:3}

This is a reference to the third channel of the file /pci/demo/irvine.pix.

  gdb:/{IMG:3}

This is a reference to the third channel of the current (base) file.

  gdb:../irvine.pix/{VEC:5}

This is a reference to vector segment five (not necessarily the fifth vector segment) on the file irvine.pix, which is one directory above the current base file.

  gdb:/{LUT:6}

This is a reference to LUT segment 6, in the current file.

  gdb:/pci/demo/irvine.pix

This is a reference to the file /pci/demo/irvine.pix. Within the API, the layer type would be LAYER_FILE.

  gdb:/{VEC:"FIELDBND"}

This is a reference to the vector segment in the current file with a layer name of FIELDBND.

Generally speaking, a GeoGateway Layer REF contains the following pieces.

REF class: Currently this is always "gdb:"; however, this should be treated as optional on input, in order that the layer "/pci/demo/irvine.pix" is the same as "gdb:/pci/demo/irvine.pix". The intention is that in the future, protocol specifiers like "ftp://ftp.pci.on.ca/pub/irvine.pix" can be used to refer to layers on the internet.

Filename: This is a filename in absolute or relative format. Either forward or backward slashes are considered acceptable as path component separators. It is unclear yet whether VMS or MacOS path formats will be acceptable. This field is optional; if omitted, the file of operation is implicitly the current one. Relative paths are interpreted relative to the path of the current file.

Layer Specifier: This takes the form "/{layer_type:layer_id}". The whole layer specifier is omitted for LAYER_FILE REF strings. The layer type is either IMG, or one of the three-letter segment type names. The layer_id is either a channel number, segment number, or layer name enclosed in double quotes.


Supported File Formats

The following file formats are supported by GeoGateway.

Supported File Formats | Read | Write
AATSR (Advanced Along Track Scanning Radiometer) | yes | no
ADRG | yes | no
ADRI | yes | no
Arc/Info Coverage | yes | no
Arc/Info Generate (AGE) | yes | yes
Arc/Info Binary GRID | yes | no
Arc/Info ASCII Grid (GRD) | yes | yes
Arc/Info Stack | yes | no
Arc/Info Raster (BIL) | yes | yes
Arc/Info Import/Export (E00) | yes | yes
Arc/Info Shapefile (SHP) | yes | yes
Arc/Info TIN (NET) | yes | no
Aries Image (DIPIX) | yes | no
ASAR (Advanced Synthetic Aperture Radar) | yes | no
Atlantis MFF Image | yes | no
AutoCAD DXF | yes | yes
AVHRR Format | yes | no
BMP (Windows and OS/2) | yes | yes
CADRG | yes | no
CCOGIF | yes | no
CDED | yes | no
CEOS | yes | no
Computer Graphic Metafile (CGM) | yes | no
CIB | yes | no
Contours Vector Files (.NTF) | yes | no
DAFIF | yes | no
DAO | yes | yes
DEM (USGS Digital Elevation Model) | yes | no
DIEPS Raster (EPH) | yes | yes
DLG (USGS Digital Line Graph) | yes | yes
DOQ (USGS Digital Orthophoto Quadrangle) | yes | no
DTED (DTD) | yes | yes
ER Mapper Compressed Rasters (ECW) | yes | yes
ER Mapper Rasters (ERS) | yes | no
EOSAT CD-ROM | yes | no
ELAS ZSoft Raster (ELAS) | yes | no
ENVI Raster (.hdr) | yes | yes
Envisat | yes | no
Erdas Imagine (.img) | yes | yes
Erdas .GIS And .LAN | yes | yes
Excel (.xls) | yes | yes
Generic ASCII Vector (GAV) | yes | yes
Graphic Interchange Format (GIF) | yes | yes
GRASS Raster/Vector (GRS) | yes | yes
Geosoft GRID File - Binary (GGF) | yes | yes
Geosoft GRID File - ASCII (GXF) | yes | yes
GTOPO30 | yes | no
Hierarchical Data Format (HDF-EOS) | yes | yes
HIDISK (HI-VIEW Image Format) | yes | no
Hyperspectral Image Data format (.VQ) | yes | no
Image Display Handler | yes | no
Idrisi Rasters | yes | yes
Idrisi Vectors | yes | yes
ILWIS Raster | yes | no
"ILWIS Vectors" | yes | no
Intergraph Raster Files | yes | no
ISDAS Spectra Library | yes | no
Joint Photographic Experts Group (JPEG) JFIF | yes | yes
JPEG 2000 | yes | yes
Land-Line NTF File (.NTF) | yes | no
LAS Image Format | yes | no
LaserScan (LSC) | yes | yes
LaserScan IFF Text | yes | yes
LGSOWG CD-ROM | yes | no
Gould LIPS (LIP) | yes | yes
MapInfo Data Interchange (MIF) | yes | yes
MapInfo Table (.TAB) | yes | yes
MERIS (Medium Resolution Imaging Spectrometer) | yes | no
MicroStation Design Files (DGN) | yes | yes
MrSID Compressed Rasters v.1.2 (SID) | yes | no
MS Access | yes | yes
NDF (NLAPS Data Format) | yes | no
NITF (NIT) | yes | yes
NTX (Caris Interchange Format) | yes | no
ODBC (Open Database Connectivity) | yes | no
OGDI (Open Geospatial Datastore Interface) | yes | no
ORACLE | yes | yes
Ordnance Survey: BaseData.GB (.NTF) | yes | no
Ordnance Survey: Boundary Line (.NTF) | yes | no
Ordnance Survey: Meridian (.NTF) | yes | no
Ordnance Survey: AddressPoint (.NTF) | yes | no
OSCAR Vector File (.NTF) | yes | no
OTHG Vector file (.OTG) | yes | no
PAMAP | yes | no
Paradox | yes | yes
PCIDSK (PIX) | yes | yes
PCX-ZSoft Raster Format | yes | yes
PLT (Geosoft Plot File) | yes | yes
PPM/PGM/PBM (PPM) | yes | yes
Raw Binary Image Format | yes | yes
Raster Product Format (RPF) | yes | no
RST - Works ASCII RST | yes | yes
SDTS DEM - Spatial Data Transfer Standard Digital Elevation Model (.DDF) | yes | no
SeaWIFS CEOS | yes | no
SeaWIFS HDF | yes | no
Siemens SICAD (SQD) | yes | no
SPANS Binary Format (top/vtx/tbb) | yes | yes
SPANS Quadtree (MAP) | yes | no
SPANS Raster (RNH) | yes | yes
SPANS Table file (TBA) | yes | yes
SPANS Vector Archive VEC/VEH | yes | yes
Spectral Library Files (.SPL) | yes | yes
SPOTView GIS-GEOSPOT | yes | no
Socet Set Annotation | yes | no
"Socet Set DTM" | yes | no
Strategi Vector File (.NTF) | yes | no
Sun Raster File (SUN) | yes | yes
Targa Raster File (TGA) | yes | yes
TIFF (TIF) | yes | yes
UK National Transfer Format (.NTF) | yes | no
UNIDSK-VMS | yes | no
UVMAP (Urban Vector Map) | yes | no
VICAR | yes | no
Vision* GINA (.gia) | yes | no
VISTA Image (.image) | yes | no
VITD (Vector Intermin Terrain Data) | yes | no
VMAP (Vector Smart Map) | yes | no
VRF (Vector Relational Format) | yes | no
WorldMap | yes | no
xBase .dbf (DBF) | yes | yes
X Window Bitmap (XBM) | yes | yes
X Window Dump (XWD) | yes | yes


AATSR (Advanced Along Track Scanning Radiometer)

GDB supports only one of the Advanced Along Track Scanning Radiometer (AATSR) product which is the ATS_AST_BP product. GDB inverts the image when it is displayed.

To get more information on the Envisat AATSR products, please consult the following web site:

http://envisat.esa.int/dataproducts/aatsr/

See Also

ASAR, MERIS


ADRG

ADRG, a specific form of "DIGEST" data distributed on CD-ROM is supported by the GeoGateway layer. ADRG CD-ROMs typically contain 3 image channels and one or more images.

Users should select the ".GEN" file which is located in a subdirectory on the disk. The name of this subdirectory varies with each disk. An example name is "/cdrom/jaus0101/jaus0101.gen".

To select an image other than the default image, the image number is specified as if it were a file in the ".GEN" file's directory. As an example, "/cdrom/cous0101/cous0101.gen/2" would select the second file on a disk.

Georeferencing information is gathered from the disk, but other text and descriptive information is not. Writing an ADRG disk is not supported by the GeoGateway layer.

See Also


ADRI

ADRI, or Arc Digitized Raster Image, is a single band raster format produced in the past by DMA. The format is supported for read and update by GeoGateway.

Users should select the ".info" file in the ADRI dataset, which normally includes the following files:

  • n32e049_ir.info <-- pick this file, which is the header
  • n32e049_ir.ovr <-- overview image ... ignored.
  • n32e049_ir.pan <-- full res raster image

ADRI files appear to be sampled on a lat/long grid, and the corresponding georeferencing will is represented. It is not apparent from the header files, what the ADRI file's datum consists of, therefore a datum of WGS84 (E012) is assumed (this may be incorrect).

ADRI data is in a flat raster format, and therefore are supported both for linking and for update of the raster data itself.

The only other auxiliary data supported with ADRI datasets is the header file itself, which will be imported as a text segment.

See Also


Arc/Info Coverage

Arc/Info 7.x binary coverages are supported by the GeoGateway library for import with a number of limitations. A coverage is selected based on the name of the coverage directory, rather than any of the files in the directory.

Point Coverages: The points (lab.adf) are imported as a single vector layer. If a pat.adf file exists with point attributes (COVER.PAT in info) then this will also be imported and attached to the points. If no point attribute table exists the points will only have one attribute, called USER-ID, containing what would be the COVER-ID field in a point attribute table.

Arc Coverage: The arcs (arc.adf) are imported as a single vector layer. If an arc attribute file exists (aat.adf or COVER.AAT in info) then it will also be imported, as well as the attributes associated with each of the arcs. Whether or not the aat.adf file exists each arc will have attributes FNODE (from node), TNODE (to node), LPOLY (left polygon), RPOLY (right polygon) which are related to topology, and not particularly useful at this time. If no aat.adf file exists the user attribute will also be attached to the arcs with the name USER-ID.

Polygon Coverage: A polygon coverage is treated as two layers: an arc coverage containing the polygon boundary arcs, and a point coverage containing the polygon centroids and any associated polygon attributes.

If the coverage has a defined projection (prj.adf) then this will also be read and associated with the vector layers. At this time only a few simple projections will be properly recognized including UTM, Geographic, and State Plane.

There is currently no support for update, or creation of new coverages.

See Also


Arc/Info Generate (AGE)

Arc/Info Generate (or Ungenerate) files are supported by the GeoGateway library. They are represented as a single vector segment, with no other auxiliary information.

Generate files do not contain any georeferencing information, therefore the vectors are assigned a georeferencing type of METRE. Generate files contain one numeric attribute which is imported and exported with the vector data.

Export of Arc/Info Generate is supported.

Arc/Info Generate vector files are exported with a type of "AGE". One, and only one vector segment may be exported, and its georeferencing system will be lost.

When exporting to Arc/Info Generate format the output file will contain either points or lines, but not both. If the segment being output contains both, the output file will contain one or the other and the user will not receive a run time warning that some of the data is being dropped.

See Also

Grid, TIN


Arc/Info Binary GRID

Arc/Info GRID data is the grid directory plus the associated file in the info directory. The actual image is stored in the w001001.adf file. The dataset can be chosen by picking one of the files in the directory except the vat.adf file, or by picking the directory itself.

Floating point image data is supported as 32-bit real raster. Depending on the range of values, integer rasters are supported as 8-bit or 16-bit integer rasters or 32-bit real rasters. The projection information is supported. If there is a vat.adf file containing attributes then the dataset is supported as a thematic raster. If an overview is present then it is used.

Export of Arc/Info GRID data is not supported.

See Also

Arc/Info Stack, Arc/Info ASCII Grid (GRD)


Arc/Info ASCII Grid (GRD)

Arc/Info ASCII Grid files are supported by the GeoGateway library. This file format is compatible with the Arc/Info ASCIIGRID and GRIDASCII commands, and consists of one raster layer.

The ASCII Grid format is supported for import and export, and is always represented as a single 16-bit signed or 32-bit floating point raster layer.

If a ".prj" file is in the same directory as the grid file, and has the same basename as the grid file it will be read to obtain projection information. Currently the only recognized projection is UTM. All other files will be imported with a MAPUNITS string of "METRE".

Is is not possible to LINK to Grid files as they are ASCII encoded.

Export of Arc/Info ASCII Grid files is supported. These files are exported with a type of "GRD".

All grid files are written out as a single 16 bit signed or 32 bit floating point raster layer. Grid files should be read into Arc/Info with the ASCIIGRID command.

No other data types can be exported to a grid file. Georeferencing coordinates are written to the file, but the georeferencing system is not. That is, .prj files are not produced.

See Also


Arc/Info Stack

Arc/Info stacks are a collection of Arc/Info grids. The stacks can be opened by selecting the stk.adf file or by selecting the stack directory.

Export of Arc/Info stacks is not supported.

See Also


Arc/Info Raster (BIL)

The Arc/Info BIL format consists of a BIL file and a HDR file.

The .HDR file contains georeferencing and structural information while the .BIL file contains just image data. The user must select the .BIL file in order to access the dataset.

8, 16 and 32 bit integer image types are supported for reading and writing. 32 bit integer images are represented in GDB as 32 bit real images.

Georeferencing information is handled for some projections; however, due to limitations in the available documentation, some Spot Image supported projections are not currently fully supported. The georeferencing is read from the .blw ESRI World File if it is present. Otherwise the .hdr file is used. See TIFF for the specifics on how georeferencing is assigned using a World File.

If the .clr file is present for an 8 bit image, then the values are read into a PCT segment for the image.

Creation of Arc/info BIL is supported. The one option for export is WORLD. Specifying the WORLD option creates an ESRI World File containing the georeferencing. The default export adds georeferencing to the .hdr file.

If a PCT segment is selected for export, then a .clr file is created.


Arc/Info Import/Export (E00)

Arc/Info Import/Export files in the form of a E00 (Data Interchange File) file are supported by the GeoGateway library for read or write operations. The three level of file compression are supported for reading (NONE, PARTIAL and FULL) and new E00 files are always generated with no compression.

When reading, various layers are available depending on what is found in the E00 file (at most one of each type):

  • ARC: Arcs, with attributes from AAT section
  • PAL: Polygons, with attributes from PAT section
  • NAT: Nodes Attributes Table
  • LAB: Labels, with attributes from PAT section
  • CNT: Centroids
  • TX6: Text

Most Arc/Info projections are supported.

Both single and double precision E00 files are supported. The default for creating new E00 files is double precision. This default can be overwritten by using the options string "SINGLEONLY" to create single precision E00 files.

INFO tables are also made visible in separate layers. Any table that is not linked to one of the layer types above will appear as a secondary table in a separate layer.

If clean topology is present in the file, then the topological layers will contain some special MetaData members.

Export of Arc/Info Import/Export files is supported. These files are exported with a type of "AII".

When writing, GeoGateway defaults to create non-topological E00 files, but applications that support GeoGateway Topology can create E00 files that contain clean Arc/Info topological coverages.

Applications that do not support topology (such as FEXPORT and most PACE programs) will create simple E00 files without topology and either:

  • An ARC section and an associated .AAT INFO table. This is the default behaviour. Also setting the create option string to "ARC" when creating the file or layer will create an ARC section.
  • A point coverage with a LAB section and an associated .PAL INFO table. Point coverages are generated when the LAYER_TYPE metadata value is set to "POINTS" when the output layer is created or if the create option string is set to "POINT".

Applications that support topology can provide a set of topological layers with clean topology and this will result in a E00 file with complete topology. If the set of layers contained an area layer, then a CNT and a LAB section will automatically be generated to accommodate the Arc/Info topology requirements. GeoGateway also recomputes the values for the arc's LENGTH attribute and the polygon's AREA and PERIMETER attributes.

Note: In the current version, automatically generated labels are placed on the polygon's centroid location (gravity centre) which does not necessarily lie inside the polygon. This will be fixed at some point in the future.

In addition to the above, all E00 files generated include:

  • Projection, if one was provided.
  • TOL (tolerances) section, with default values.
  • .BND (bounds) INFO file containing coverage extents.
  • .TIC (registration control points) INFO file with 4 TICs corresponding to the 4 corners of the coverage.

See Also


Arc/Info Shapefile (SHP)

Arc/Info Shapefile files are supported by the GeoGateway library for import and export. The Shapefile format contains vector and attribute information. Typically, datasets include three files with a common basename and the extensions .shp, .shx, and .dbf. Shapefiles do not contain projection information, therefore all vectors will be reported as being in the georeferencing system "METRE" when imported.

Shapefiles are currently supplied in thirteen types: POINT, ARC, POLYGON, MULTIPOINT, POINTZ, ARCZ, POLYGONZ, MULTIPOINTZ, POINTM, ARCM, POLYGONM, MULTIPOINTM and MULTIPATCH. The polygon and arc layer types contain what ESRI calls multi-part shapes. For instance, a multipart polygon would be the outer boundary and all the interior holes in the polygon. The multiple parts are maintained using the RingStart mechanism.

The POINTM, ARCM, POLYGONM, and MULTIPOINTM shapes contain an additional "measurement" value at each vertex. These measurement values are ignored by GeoGateway and lost in the translation process.

The POINTZ, ARCZ, POLYGONZ, and MULTIPOINTZ are three 3D shapes whereas as the POINT, ARC, POLYGON and MULTIPOINT types are 2D (Z always zero). The Z, and M shape types are new in ArcView 3.x.

The MULTIPATCH shape is a special complex type for representing TINs. The tesselation information inherent in the multipatch is lost by GeoGateway, however, all the data points are preserved on read.

The Shapefile attributes are stored in an xBase (.dbf) file which is also supported as a standalone GeoGateway format. Further details on the .dbf translator can be found in the xBase topic.

Shapefiles are produced by ArcView, and Arc/Info. Within Arc/Info use the ARCSHAPE command to export a coverage to a shapefile, or the SHAPEARC command to import a shapefile and build a coverage.

Export of Arc/Info Shapefiles is supported. These files are exported with a type of "SHP".

Only one vector layer may be exported to a single shapefile.

The output filename for the shapefile to be created should have an extension of .shp or .shx. When data is exported, three files are created with the same basename, and the extensions .shp, .shx and .dbf. Together these make a dataset with attributes.

Shapefiles don't have georeferencing, nor are any other datatypes other than vector layers supported. Georeferencing information usable by GeoGateway software is written to an .aux file, but this will not be supported by ArcView, or Arc/Info.

The option value can be used to select a layer type to assign to the created Shapefile. If no options are specified, the system will select either MULTIPOINT, ARC, or POLYGON depending on the nature of the first shape written to the file, or the LAYER_TYPE metadata.

 option = "POINT"              | each shape is a single point
 option = "ARC"                | each shape is set of polylines
 option = "MULTIPOINT"         | each shape is a set of points
 option = "POLYGON"            | each shape is a set of closed arcs
 option = "POINTZ"             | each shape is a single 3d point
 option = "ARCZ"               | each shape is set of 3d polylines
 option = "MULTIPOINTZ"        | each shape is a set of 3d points
 option = "POLYGONZ"           | each shape is a set of 3d closed arcs

Note that it is not currently possible to write shapefiles with MULTIPATCH shapes in them. POINT and POINTZ layers can only contain shapes with a single point. If no layer type is given as an option, one will be selected based on an internal set of rules.

See Also


Arc/Info TIN (NET)

Arc/Info TIN files, produced by the UNGENERATETIN command with the NET option, are supported for read access by the GeoGateway library. Arc/Info TIN files have an extension .net.

The triangular tin elements are read as triangular whole polygons (four vertices each). Each vertex of each polygon has a Z coordinate indicating the elevation of that corner of the mesh element. This organization is suitable for use as a TIN with the OrthoEngine DEM Generation tools.

Arc/Info TIN files contain no projection information, therefore the files are treated as being in generic metres.

The vectors will have no attributes. No other information is stored in the Arc/Info TIN files.

See Also


Aries Image (DIPIX)

Some Aries (DIPIX) image files (.i suffix) are supported by the GeoGateway library. Only integer files (16/32 bit) are supported.

On the VAX platform correct georeferencing will be accessed, while on other platforms the pixel size is unreadable, and will be defaulted to 1. In this case only the top left corner position is accurate.

Existing Aries files may be written to, but new files cannot be created by Works programs.


ASAR (Advanced Synthetic Aperture Radar)

Most common forms of Advanced Synthetic Aperture Radar (ASAR) files are supported by the GDB library.

ASAR has four imaging modes. Amongst these modes GDB supports: the ASAR Image Mode (IM), the ASAR Alternating Polarization Mode (AP) and the ASAR Global Monitoring Mode (GM). The Wide Swath Mode mode (WS) is not supported yet. Under the WS mode, GDB only supports the ASA_WS_BP product. The image of the ASA_WS_BP product is however inverted (West is right and East is left).

In the ASAR Image Mode, images of ASA_IMM_1P, ASA_IMP_1P and ASA_IM__BP products are flipped (North is down and South is up). In the Alternating Polarization Mode, images are flipped for the following products: ASA_AP_1P and ASA_APP_1P. Finally, in the ASAR Global Monitoring Mode, images of the ASA_GM_1P and ASA_GM1_1P products are flipped.

To get more information on the Envisat ASAR products, please consult the following web site:

http://envisat.esa.int/dataproducts/asar/

See Also

MERIS


Atlantis MFF Image

Images in the Atlantis SAR Processor (MFF) format are supported by the GeoGateway library for reading. This is the format produced by the SAR Processor product distributed by PCI.

Most images in MFF format are in the complex domain (each pixel consists of a real and an imaginary component). When read, each complex image is represented by three image channels. One contains the real component, the second contains the imaginary component, and the third contains the magnitude of the first two components.

MFF files consist of a header file (e.g., AZC.hdr) which contains information such as the image size and a separate file for each image layer. To select an MFF file use the name of the header file (e.g., AZC.hdr) not the name of one of the image files (e.g., AZC.X00).

The header file must have "IMAGE_FILE_FORMAT = MFF" as the first line. This may not exist in some older Atlantis MFF files, and can be added by hand.

No georeferencing or other auxiliary data is imported with MFF files. Currently there is no support for exporting in MFF format, nor can an MFF file be linked to using the LINK PACE program.


AutoCAD DXF

The GeoGateway library supports AutoCAD vectors (version 14 or less) in the form of a DXF (Data Interchange File) file for both read and write operations, with certain limitations.

For read operations the supported vector entities are

  • 3DFACEs
  • ATTDEFs
  • ATTRIBs
  • LINEs
  • MLINEs
  • POINTs
  • POLYLINEs
  • SOLIDs
  • TRACEs
  • RAYs
  • XLINEs

NOTE that POLYLINEs 2D with a START POINT, END POINT, and RADIUS are not supported.

ARCs, CIRCLEs and ELLIPSEs are supported by approximating them with line segments.

TEXTs and MTEXTs are also supported: the character string is stored in the "TextString" attribute and the orientation in the "Angle" attribute.

The non-vector entities, INSERT and BLOCK are supported.

On version 14, the definition of new Entity type (CLASSES SECTION) is supported, for all vector type read.

In read access, a Representation Table (RST) is built based on the drawing information that is available (line width, LTYPEs, etc.). Since this table is built while reading the file, it should be queried only after the file has been completely read in. Each entity read is given a "REPCode" attribute that points to an entry in this RST. Finally there is only one RST for the whole file, even if there are several layers.

Export of AutoCAD DXF files is supported. AutoCAD DXF files are exported with a type of "DXF".

For write operations the only entities that are written out for now are LINE, POLYLINE, TEXT and POINT entities. Any ARC, CIRCLE or ELLIPSE entity that may have been read in will be written out as a series of approximating line segments.

It is also possible to provide an RST when exporting. In this case the line types will be set in the new file. An entity with only 1 node and a "TextString" attribute will be written with the type TEXT, with or without an RST.


AVHRR Format

Various AVHRR data formats are supported for reading by the GeoGateway library. AVHRR refers to the sensor on NOAA satellites which produces this type of data.

AVHRR imagery typically contains 5 channels (2 visible channels and 3 thermal channels). Images are either 409 pixels wide (low resolution) or 2048 pixels wide (high resolution).

Supported AVHRR formats include:

  • Level 1b 8-bit/10-bit/16-bit HRPT/LAC
  • Level 1b 8-bit/10-bit/16-bit GAC
  • Dartcom 16-bit HRPT
  • Satlantic 16-bit HRPT
  • Quorum Qtrack 16-bit HRPT
  • 16-bit HRPT Minor Frame
  • Dundee 16-bit HRPT
  • AVHRR CEOS (Raw AVHRR CCT Image Format)

Level1b channel selection is supported (Level1b data may contain less than 5 bands).

When FIMPORT is applied to AVHRR data, a text segment containing orbital element values and calibration data is created. For Level 1b HRPT/LAC and GAC formats, a GCP segment containing up to 255 GCPs is also created. For the Level 1b HRPT/LAC and AVHRR CEOS formats, an orbit segment is created. For details please see the subtopic descriptions of the individual file formats.


LAC/HRPT Level 1b Format

Level 1b HRPT/LAC is high resolution (1 km) data which can be obtained via the World Wide Web (http://www.saa.noaa.gov). The Level 1b designation indicates that this data is an enhanced form of raw HRPT data. Level 1b data contains extra information such as Earth location values in lat/long. This Earth location data is used to form a grid of up to 255 GCPs, which are stored in a GCP segment when FIMPORT is applied to Level 1b data. FIMPORT will also create a text segment which contains information such as the satellite name, date/time of image capture, orbital (ephemeris) element values, and some calibration data.

For the Level 1b HRPT/LAC format, FIMPORT also creates a binary orbit segment containing per-scanline quality, calibration, and timing information.


GAC Level 1b Format

Level 1b GAC data is similar to Level 1b HRPT/LAC data except that it is of lower resolution (4 km).


Dartcom 16-bit HRPT Format

A Dartcom 16-bit HRPT image is stored in the form of six component files. Only the RAW and RPD files are used by FIMPORT. A Dartcom RAW file contains the scanline or video data. This is the file which must be used in conjunction with FIMPORT. The Dartcom RPD file is an auxiliary text file that contains information such as the satellite name, date/time of image capture, and orbital element values. The information from the RPD file (if present) is read into a text segment by FIMPORT. There is no Earth location data in Dartcom RAW or RPD files, hence, FIMPORT does not create a GCP segment for the Dartcom format. A RPD file must have the same basename as the corresponding RAW file, but with a different extension. It must also reside in the same directory as the RAW file.


Satlantic 16-bit HRPT Format

A Satlantic 16-bit HRPT file has a header from which information such as the satellite name and orbital element values can be extracted. This information is placed into a text segment by FIMPORT.

The Satlantic format does not have Earth location information, hence, FIMPORT does not create a GCP segment for this format.


Quorum Qtrack 16-bit HRPT Format

A Quorum Qtrack 16-bit HRPT file begins with two header frames. The first is an "ephemeris data" frame, containing the satellite name and orbital element values. The second is a "start data time stamp" frame, containing the time of image acquisition to the nearest second. The information in these two frames is extracted and placed into a text segment by FIMPORT. The third and subsequent frames in a Quorum file are treated as HRPT scanline frames. FIMPORT does not recognize resync frames in a Quorum file.

The Quorum format does not have Earth location information, hence, FIMPORT does not create a GCP segment for this format.


16-bit HRPT Minor Frame Format

A 16-bit HRPT Minor Frame file contains data (scanline) records, each with a length of 22180 bytes. There is no header record in this format. This format does not contain any information about the year of image acquisition, hence, this quantity will not be available in the text segment created by FIMPORT.

The HRPT Minor Frame format does not have Earth location information, hence, FIMPORT does not create a GCP segment for this format.


Dundee 16-bit HRPT Format

A Dundee 16-bit HRPT file has a header from which information such as the satellite number and year of image acquisition can be extracted. This information is placed into a text segment by FIMPORT. The header has a length of 22180 bytes.

The Dundee format does not have Earth location information, hence, FIMPORT does not create a GCP segment for this format.


AVHRR CEOS Format

The AVHRR CEOS (Raw AVHRR CCT Image Format) is supported. The specifications for this format are outlined in the following document:

 DMD-TM #90-678F
 "Standard Raw AVHRR CCT Image Format Specifications"
 Canada Centre for Remote Sensing

Typically, AVHRR CEOS data exists in tape format. A single CEOS scene consists of 5 tape files: volume directory file, leader file, image file, trailer file, and null volume directory file. It is possible to transfer the 5 tape files corresponding to a single scene into 5 disk files. In order to import the 5 disk files corresponding to a CEOS scene, it is necessary to supply the volume directory file as the input file (FILI parameter) and ensure that the 5 disk files follow the appropriate naming convention. As an example, these are the names of 5 disk files corresponding to a CEOS scene: myscene.vol, myscene.led, myscene.img, myscene.trl, and myscene.nul. Note that only the volume directory file and image file are mandatory. All of the files corresponding to the same scene must reside in the same directory.

For the AVHRR CEOS format, FIMPORT creates a binary orbit segment containing per-scanline quality, calibration, and timing information.


Some Definitions

  • AVHRR: Advanced Very High Resolution Radiometer
  • NOAA: National Oceanic And Atmospheric Administration
  • SAA: Satellite Active Archive
  • HRPT: High Resolution Picture Transmission
  • LAC: Local Area Coverage
  • GAC: Global Area Coverage


BMP (Windows and OS/2)

Windows and OS/2 BMP files are simple raster files. They are a common import and export format for applications under Windows and OS/2.

GeoGateway supports the image variants that have 1, 4, 8, or 24 bits per pixel. GeoGateway can read 4-bits per pixel BMP files but does not support the export of such files. BMP files must be uncompressed to be read by GeoGateway. GeoGateway will produce a 24-bit file if three channels are saved, an 8-bit file if one channel is saved, and a 1-bit file if a bitmap is saved. It is not legal to specify any other number of channels.

GeoGateway will update any type of supported BMP file, but if asked to create a BMP file, it will create the Windows variant.

Export

Export of Windows BMP files is supported. BMP files are exported with a type of "BMP".

Windows and OS/2 BMP files are supported for reading. However, only Windows BMP files can be exported. The user may specify 1 or 3 channels or 1 bitmap to be written to the BMP file. If one channel is selected, then a PCT may also be written.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

CADRG

See: RPF or NITF.


CCOGIF

The GeoGateway library supports the CCOGIF 2.3 vector format. This format was produced by the Canadian Council On Geomatics as a standard file exchange format for digital spatial data.

Only read access to CCOGIF format is available. No attributes are imported with CCOGIF vectors, and the "area" structure is ignored.

Projection information is extracted from the CCOGIF file, however, only the Transverse Mercator (TM) projection has been tested.


CDED

The Canadian Digital Elevation Data (CDED) consists of an ordered array of ground elevations at regularly spaced intervals. These CDED are based on National Topographic System (NTS) maps at the scale of 1:250 000. Other complementary sources include elevation data, aerotriangulation control points, and geodetic control points.

The coverage of every file corresponds to half an NTS map sheet, which means that there are western and eastern parts to the CDED for every NTS map at the 1:250 000 scale when necessary. The grid spacing is based on geographic coordinates at a maximum resolution of 3 arc seconds and a minimum resolution of 12 arc seconds depending on latitude. It consists of elevation data recorded in metres relative to mean sea level based on the NAD83 horizontal reference datum.

Quality control is implemented throughout the production process. These CDED are produced jointly by the Centre for Topographical Information (CTI) and the Canadian Forest Service, Ontario Region (CFS). All CDED files are produced using ANUDEM (Australian National University Digital Elevation Models) software.

CDED have assumed a major role in digital mapping. They are used in geographic information systems (GIS) for land-management applications. CDED play the same roles that contours and relief shading do on conventional paper maps, but are more powerful analytically. In addition to providing estimated values of elevation points, CDED can be used to determine orientation and the slope of each point when used in GIS applications. CDED can also be used for terrain modeling, for calculating the influence of the terrain on line-of-sight, for radar imaging, for simulating flooding, and similar applications.

For more information on CDED, please see the CDEDSPECS.PDF file, located in the manuals\misc directory on your Geomatica installation CD.


CEOS

CEOS is a multi-file/section format used by the remote sensing community for SAR imagery data.

Due to the nature of CEOS, the file naming is not consistent across products. The translator attempts to locate the proper files for reading. The image file normally has the ".img" extension except in the case of RADARSAT data which uses the "dat_01.001" name for the image file.

Since CEOS can contain complex data, this data is represented in GDB as two separate channels.

As well, the CEOS translator will gather projection and orbital information from the CEOS ancillary data contained in the header portions of the CEOS files.


Computer Graphic Metafile (CGM)

Computer Graphic Metafile(CGM v4.0) implementation for NITFS(The National Imagery Transmission Format Standards ) is a subset of the Federal Information Processing Standard FIPS PUB 128 and complies with the specifications established in FIPS PUB 128. The CGM are supported by the GeoGateway library as symbol assignment file for import and view, also GeoGateway can open a CGM file as General file format.

The CGM structure is explained fully in the FIPS PUB 128 document. We also can get document at: http://164.214.2.59/vpfproto/geosym.htm. The CGM implementation for NITFS support for input interpretation and are grouped by element class.

Basic content of CGM file format is showed below:

a. Metafile Delimiter Elements

           BEGIN METAFILE
           BEGIN PICTURE
           BEGIN PICTURE BODY
           END PICTURE
           END METAFILE

b. Metafile Descriptor Elements

           METAFILE VERSION (version = 1)
           METAFILE ELEMENT LIST
           METAFILE DESCRIPTION
           FONT LIST

c. Metafile Picture Descriptor Elements

           COLOR SELECTION MODE (1 = direct)
           EDGE WIDTH SPECIFICATION MODE (0 = absolute)
           LINE WIDTH SPECIFICATION MODE(0 = absolute)
           VDC EXTENT

d. Metafile Graphical Primitives with Associated Attributes

           Text Primitive Element with Attributes

               TEXT COLOR
               CHARACTER HEIGHT
               TEXT FONT INDEX
               CHARACTER ORIENTATION
               TEXT

           Filled Area Primitive Elements with Attributes

               FILL COLOR
               INTERIOR STYLE (1= solid or 4 = empty)
               EDGE VISIBILITY (1 = on)
               EDGE WIDTH
               EDGE TYPE (1=solid or 2=dashed)
               EDGE COLOR
               POLYGON

               ELLIPSE
               ELLIPTICAL ARC CLOSE
               RECTANGLE
               CIRCLE
               CIRCULAR ARC CENTER CLOSE

           Line Primitive Elements with Attributes

               LINE WIDTH
               LINE TYPE (1=solid or 2=dashed)
               LINE COLOR

               POLYLINE
               ELLIPTICAL ARC
               CIRCULAR ARC CENTER

Georeferencing information is unsupported.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

CIB

See: RPF or NITF.


Contours Vector File (.NTF)

Land-Form PANORAMA Contour Data in NTF(NTF v2.0 level 1)

Digital Height Data at nominal 1:50 000 scale available as contours or Digital Terrain Models (DTMs), and sold in tiles. Created from Ordnance Survey's "Landranger" paper maps. Geographical features each have individual feature codes. Contours is especially useful for customers who need large areas of height data.

NTF Contours is supported by the GeoGateway library for import and view. Two vector layers may be used to display NTF file's two data set:

  1. point
  2. line

Structure of features

The structure of each different feature is as follows:

  1. Point Feature:(these features are spot heights)
    • a Point Record [POINTREC] 15
    • a Geometry Record [GEOMETRY1] 21
  2. Line Feature:
    • a Line Record [LINEREC] 23
    • and a Geometry Record [GEOMETRY1] 21
    • and maybe one or more Continuation Records[CONTREC] 00 to extend the Geometry Record

When a contour falls entirely within a single tile its first and last coordinate pair are coincident, unless the alignment is broken for clarity or the contour is split into several features. When a contour line crosses a tile edge, the contour line record starts/ends at the crossing point on the tile edge.

Coordinate referencing system

All coordinates are measured from the local origin, which is the South West corner of a tile. To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the South West corner of the tile. The South West corner coordinates are contained within the {X_ORIG} and {Y_ORIG} fields of the Section Header Record [SECHREC].

See UK National Transfer Format (.NTF) for information on georeferencing.


DAFIF

DAFIF (Digital Aeronautical Flight Information File Edition 5) data are supported in GeoGateway. The airport, runway, heliport and navaid data are supported as point layers with some attributes available. This format is only supported for reading.

To open a DAFIF dataset in a file chooser, click on Choose Directory. In the tree list, pick the directory which is the parent of the FULLALL directory. GeoGateway only uses the FULLALL (full database) directory.


DAO

DAO (Data Access Objects) is a Microsoft library that allows access to the database files that Microsoft Jet database engine can access. For GeoGateway this list includes Microsoft Access, Excel and Paradox files. Databases which are accessible through ODBC may also be accessible using DAO. See ODBC.

To open an Access, Excel or Paradox file, choosing it in the file selector. Note that files without geographic data do not display in the map, but may be viewed with the 'View Attributes' command.

The file will be searched for fields X,Y or Lon,Lat and if found it will use this information to create a point layer for the layer.


DEM (USGS Digital Elevation Model)

Both USGS 7.5 minute and 1 degree ASCII DEM files are supported for reading by the GeoGateway library. USGS DEM files contain one 16-bit channel containing elevation data, but no auxiliary data. The UTM georeferencing information for the elevation data is also loaded from the DEM file.

By definition USGS DEM files are supposed to be based on the NAD 27 (E0) datum, however, PCI has noticed some that where based on the NAD 83 datum. The GeoGateway library cannot detect this, and will always report DEM files as being E0 (NAD27).

USGS DEM elevations may be metres, feet, or perhaps even other units. Upon import the DEM channel will be marked with metadata indicating an ELEVATION_UNITS of either FEET, or METRE. Not much PCI software utilizes this metadata directly, but it can be inspected by a user, and a simple model can be used to convert between feet, and metre units.

Areas of missing data (void areas) in USGS DEM files are set to a background value of -32767. The NO_DATA_VALUE metadata is attached to the channel indicating the background value (-32767).

The PACE task DEMWRIT may be used to write USGS DEM files; however, export support is not currently supported through GeoGateway.


DIEPS Raster (EPH)

The GTE DIEPS 5 software's native raster format is supported for read, link, update, and export. DIEPS datasets normally consist of a data file with no extension, and a header file with the extension .eph. The .eph header file should be selected in order to import DIEPS files.

Only eight-bit DIEPS files are supported at this time.

Projection and ground control information is neither imported from DIEPS, nor exported to DIEPS files, at this time.

The palette within the .eph file will be imported as a PCT segment, and the entire .eph header file will be imported as a text segment.

Export of DIEPS Raster files is supported. DIEPS files are exported with a type of "EPH".

The generated header file will have an extension of .eph (regardless of the extension in FILO), and the data file will have no extension.

FEXPORT can only generate files with one eight bit band. No vector data, or other auxiliary data can be written to .eph files. Only raster data is supported.

Data can also be exported to DIEPS via JPEG, NITF, and TIFF formats, though an extra import step will be required within DIEPS.


DLG (USGS Digital Line Graph)

USGS DLG (Digital Line Graphs) are supported for reading and writing by the GeoGateway Library. The full topology of a DLG file is not retained during a read operation. Any Area information present in a DLG file will not be retained. In addition, only the first attribute code of a line will be retained, all others will be skipped.

DLG files written out by this program are equivalent to DLG level 2 files. When DLG files are written out, a node list is generated, and node-to-line as well as line-to-node linkages are generated. Since the full topology of the file is not retained, the left and right area fields of a Line Record will be initialized with a -1.

USGS DLG files may be created by Works programs. The DLGREAD and DLGWRIT programs may also be used to import and export DLG format vector data.


DOQ (USGS Digital Orthophoto Quadrangle)

USGS digital orthophotos are supported by the GeoGateway library for read only. Digital orthophotos with embedded DEM information are not supported. Two formats of the DOQ format are supported. The traditional unlabelled header format, in use before 1997, and the new keyworded header distributed on, and after the summer of 1997.

Projection information (always UTM) is extracted from DOQ files.

All the header fields of the new keyworded DOQ format is extracted as metadata attached to each of the image channels. All this metadata is prefixed with "DOQ_".

Existing DOQ files can be written to, but new files cannot be created. The PACE program LINK may also be used to access DOQ image data.


DTED (DTD)

The DMA's (Defense Mapping Agency) DTED (Digital Terrain Elevation Data) level 1 and level 2 format is supported by the GeoGateway library for import, update and export.

The GeoGateway layer supports the CD-ROM DTED format (as defined in MIL-PRF-89020A). Under the specification, these files have an extension .dt1, or .dt2. They contain a user header label, data set identification record, accuracy description record, and the digital elevation information. The CD-ROM DTED format also implies a hierarchical arrangement of files based on georeferencing. The GeoGateway layer does not understand this hierarchy and only knows how to read a single DTED file at a time.

A DTED file covers a 1 degree by 1 degree area, but its resolution varies depending on the latitude of the file, and the level of the format.

DTED files contain one 16-bit signed channel of elevation data and no auxiliary data. The LONG/LAT WGS84(D000) georeferencing bounds for the elevation data are preserved. Note that the bounds are slightly larger than the 1degree x 1degree cell the file represents as the edge pixels of the dataset are centered on the cell boundaries. Treated as an area, these extend slightly overlap the cell boundaries. Adjacent DTED files will shared one row, or column of values on their common border.

Export of DTED files is supported. These files are exported with a type of "DTD". Only one channel may be exported to the DTED files.

DTED files georeferencing must exactly match a cell boundary, and will be automatically adjusted if inappropriate georeferencing is written. If a DTED file is created with a name matching the cell naming conventions (e.g. "e001n010.dt1") then the georeferencing of the cell will be automatically applied.

DTED files must match one of a limited set of configuration which will determine the level of the file. According to the standards these resolutions are appropriate to particular latitudes.

DTEDLVL    Latitude           Long/Lat Res. (arc seconds)   Pixels/Lines
-------    --------           ---------------------------   ------------
   1       0-50  (north/south)     3  x  3                  1201 x 1201
   1       50-70 (north/south)     3  x  6                  1201 x 601
   1       70-75 (north/south)     3  x  9                  1201 x 401
   1       75-80 (north/south)     3  x  12                 1201 x 301
   1       80-90 (north/south)     3  x  18                 1201 x 201
   2       0-50  (north/south)     1  x  1                  3601 x 3601
   2       50-70 (north/south)     1  x  2                  3601 x 1801
   2       70-75 (north/south)     1  x  3                  3601 x 1201
   2       75-80 (north/south)     1  x  4                  3601 x 901
   2       80-90 (north/south)     1  x  6                  3601 x 601

Because of the difficulty of creating and writing to DTED cell files appropriately, it is suggested that the DTEDWRIT PACE task normally be used to writes the DTED cell files related to a source DEM.

The PACE task MIDTED can be used to read DTED files from tape into a PCI .pix database.


ER Mapper Compressed Rasters (ECW)

The GeoGateway library supports ER Mapper's Compressed Raster Formats (ECW) for live linking, import and export. ER Mapper's Compression and Decompression Software Devlopment Kits (v.2.46) were used to introduce this functionality in PCI products and it is, therefore, only available on 32-bit Windows operating systems.

A compressed image is one that has been reduced in size, but still maintains an almost perfect version of the original. There are various compression techniques, but it is wavelet compression that is used by ER Mapper's software. This technique enables very high compression rates where a typical colour image can be compressed to less than 2% to 5% of its original size (50:1 to 20:1 compression ratios). This means that, at 20:1 compression, it is possible to compress 500 MB of colour imagery down to 25 MB.

Please note that in order to compress a file of greater than 500 MB, you are required to buy additional software from ER Mapper.

Lossless compression, as the name implies, results in a compressed image that can be perfectly reconstructed to be identical to the original image. Its main advantage is this ability of perfect reconstruction, but its main disadvantage is that it is typically limited to a compression of 2:1. Wavelet compression, however, is a lossy compression, which means that some information is thrown away in order to achieve the much higher compression rates than are possible with lossless compression. Here, the main advantage is the higher compression ratios, but the disadvantage is that the compressed image can not be perfectly reconstructed to be identical to the original.

An ER Mapper Compressed Raster consists of a single file with an ECW extension. Sometimes an accompanying file with an ERS extension is included. This ".ERS" file will contain metadata about the ECW file, but is only used by ER Mapper software. It is not used while importing or viewing ECW files in PCI software and a ".ERS" file is not created during export. The relevant data is contained within the ".ECW" file itself.

PCI reads and applies the georeferencing information contained in the ECW file. Many of ER Mapper's supported spheroids and datums are translated to use the same in PCI products. Please see the subsection "Supported ER Mapper Datums/Spheroids" for a comprehensive list of the datums supported and the PCI datums used for them.

Additionally, ER Mapper's supported SPCS (State Plane Coordinate System), UTM Metre projections and their Lambert1 and Lambert2 projections are fully supported in PCI products. Please see the subsection "Supported ER Mapper Projections" for a comprehensive list of the projections supported.

When compressing imagery during Export, the following "Target Compression Ratios" are used by default:

Greyscale     15:1
RGB           25:1

The user has the ability to change the Target Compression Ratio by entering an integer value in the Options field of the export dialogue. ER Mapper suggests the following guidelines when selecting the best compression ratio to use:

Colour Image for high quality printed maps          25:1
Colour Image for Internet or email distribution     40:1
Greyscale Image for high quality printed maps       10:1 to 15:1
Greyscale Image for Internet or email distribution  15:1 to 30:1

Depending on the imagery, your final compression ratio may actually be higher than the target compression. The compression engine uses the target as a measure of how much information content to preserve. If your image, however, has large, similar areas that are well suited to compression, a greater rate of compression may be achieved while still maintaining the desired information content. It is important to note that this does not affect the quality of the resulting compressed image.


Supported ER Mapper Datums/Spheroids

PCI reads and applies the georeferencing information contained in the ECW file. Many of ER Mapper's supported spheroids and datums are translated to use the same in PCI products. The following is a comprehensive list of the datums supported and the PCI datums used for them:

ER Mapper Code     PCI Code
--------------     --------
ADINDAN            D002
ARC1950            D014
ARC1960            D023
BOGOTA             D035
CAPE               D040
CARTHAGE           D042
CHUA               D044
CLRK1866           E000
CMPOINCH           D038
CORRALLEG          D045
ED50               D050
ED50EGYT           D054
INDIAN54           D077
INDIAN75           D078
KERTAU             D085
LEIGON             D088
LUZON11            D090
MAHE71             D092
MPORO              D099
NAD27              D-01
NAD83              D-02
OSGB36             D131
PSAD56             D141
PTNOIRE            D139
QATAR              D152
QORNOQ             D153
SAD69              D162
TANANAR            D176
TIMBALAI           D177
TOKYO              D178
WGS84              D000


Supported ER Mapper Projections

PCI reads and applies the georeferencing information contained in the ECW file. ER Mapper's supported SPCS (State Plane Coordinate System), UTM Metre projections and their Lambert1 and Lambert2 projections are fully supported in PCI products. The following is a comprehensive list of the ER Mapper projections that are supported:

ER Mapper Projection Codes
==========================

lambert1
--------
LM1ADEN     LM1AFNDX    LM1ALGND    LM1ALGSD    LM1BANG
LM1BLSEA    LM1BURMA    LM1CARIB    LM1CAUC     LM1COLC
LM1CORSE    LM1FRA1D    LM1FRA1G    LM1FRA2D    LM1FRA2G
LM1FRA3D    LM1FRA3G    LM1FRA4D    LM1FRA4G    LM1FRAND
LM1FRE1D    LM1FRE1G    LM1FRE2D    LM1FRE2G    LM1FRE3D
LM1FRE3G    LM1FRE4D    LM1FRE4G    LM1GREN1    LM1GRNOR

LM1GRSUD    LM1IND1     LM1IRAN     LM1IRAQ     LM1JAFT
LM1JAMTR    LM1KANG     LM1LEVD     LM1LEVG     LM1LIBS
LM1LIBYA    LM1MORND    LM1MORSD    LM1NEP1     LM1NEP2A
LM1NEP2B    LM1NPG      LM1PA2B     LM1PA2BY    LM1PAK1
LM1PAK1Y    LM1PAK2     LM1PAK2Y    LM1PB1D     LM1PB1G
LM1POL      LM1ROM      LM1SHAB     LM1SPAIN    LM1SPANM
LM1SYRSD    LM1SYRSG    LM1TUNND    LM1TUNSD    LM1TURK
LM1USSR

lambert2
--------
LM2AF113    LM2AF114    LM2AF72     LM2AF92     LM2AF93
LM2AF94     LM2AF95     LM2AFE      LM2AFSH     LM2ALG
LM2ARAB     LM2AREA1    LM2AREA2    LM2AREA3    LM2ARKNF
LM2ARKNM    LM2ARKSF    LM2ARKSM    LM2ASEAN    LM2ASIA
LM2AUST     LM2AZERB    LM2BAREN    LM2BELG     LM2BKSEA
LM2BLACK    LM2BLCKS    LM2NLKSE    LM2BNOR     LM2BOF
LM2BURMA    LM2CAL1F    LM2CAL2F    LM2CAL3F    LM2CAL4F
LM2CAL4M    LM2CAL5F    LM2CAL5M    LM2CAL6F    LM2CAL7F
LM2CAMER    LM2CAN      LM2CAN60    LM2CAN78    LM2CBRAZ
LM2CEGYP    LM2CFRAN    LM2CHBON    LM2CHECS    LM2CHEOF
LM2CHIN     LM2CHINA    LM2CHRUS    LM2CHYS     LM2COLCF
LM2COLNF    LM2COLSF    LM2COLUM    LM2COMAN    LM2CONNF
LM2CONNM    LM2CSPN     LM2EE       LM2EGYPT    LM2EUNDX
LM2EURO     LM2FKLDS    LM2FLANF    LM2FRANC    LM2GULF
LM2H6       LM2IND76    LM2IND77    LM2IND78    LM2IND96
LM2IND97    LM2IND98    LM2INDIA    LM2IOWNF    LM2IOWSF
LM2IRAM     LM2JEBCO    LM2JUNGB    LM2KALIM    LM2KANNF
LM2KANNM    LM2KYNFT    LM2KYNM     LM2KYSFT    LM2LANDS
LM2LANFT    LM2LANM     LM2LAOFT    LM2LASFT    LM2LASM
LM2MAINE    LM2MARYF    LM2MASIF    LM2MASIM    LM2MASMF
LM2ME       LM2ME1      LM2MEDIT    LM2MICCF    LM2MICNF
LM2MICSF    LM2MINCF    LM2MINNF    LM2MINSF    LM2MOCFT
LM2MON      LM2MONFT    LM2MOSFT    LM2MTCFT    LM2MTM
LM2MTNFT    LM2MTSFT    LM2NBRUN    LM2NCAFT    LM2NBSEA
LM2NDNFT    LM2NDNM     LM2NDSFT    LM2NEBM     LM2NEBNF
LM2NEBSF    LM2NEPAL    LM2NEWYF    LM2NFA      LM2NFB
LM2NHEM     LM2NSEA     LM2NZN      LM2NZS      LM2OHINF
LM2OHISF    LM2OKLNF    LM2OKLNM    LM2OKLSF    LM2OKLSM
LM2ORENF    LM2ONH25    LM2ORESF    LM2OSTER    LM2PANFT
LM2PASFT    LM2PRMB     LM2PRV1F    LM2PRV2F    LM2RUSS
LM2RUSS1    LM2RUSS2    LM2RUSS3    LM2RUSS4    LM2RUSS5
LM2RUSS6    LM2SCHIN    LM2SCHNS    LM2SCNFT    LM2SCSFT
LM2SDNFT    LM2SDSFT    LM2SEYCH    LM2SHAW     LM2SYRIA
LM2TAIW     LM2TARIM    LM2TENNF    LM2TIMAN    LM2TURK
LM2TURKG    LM2TURKY    LM2TXCF     LM2TXCM     LM2TXNCF
LM2TXNCM    LM2TXNF     LM2TXSCF    LM2TXSCM    LM2TXSF
LM2TXSM     LM2UKN      LM2USSR     LM2USSR1    LM2UTHCF
LM2UTHNF    LM2UTHSF    LM2VEN      LM2VENCN    LM2VENPC
LM2VIET     LM2VIRNF    LM2VIRSF    LM2WISCF    LM2WISNF
LM2WISSF    LM2WSHNF    LM2WSHSF    LM2WVANF    LM2WVASF

utm
---
NUTM01      NUTM02      NUTM03      NUTM04      NUTM05
NUTM06      NUTM07      NUTM08      NUTM09      NUTM10
NUTM11      NUTM12      NUTM13      NUTM14      NUTM15
NUTM16      NUTM17      NUTM18      NUTM19      NUTM20
NUTM21      NUTM22      NUTM23      NUTM24      NUTM25
NUTM26      NUTM27      NUTM28      NUTM29      NUTM30
NUTM31      NUTM32      NUTM33      NUTM34      NUTM35
NUTM36      NUTM37      NUTM38      NUTM39      NUTM40
NUTM41      NUTM42      NUTM43      NUTM44      NUTM45
NUTM46      NUTM47      NUTM48      NUTM49      NUTM50
NUTM51      NUTM52      NUTM53      NUTM54      NUTM55
NUTM56      NUTM57      NUTM58      NUTM59      NUTM60

SUTM01      SUTM02      SUTM03      SUTM04      SUTM05
SUTM06      SUTM07      SUTM08      SUTM09      SUTM10
SUTM11      SUTM12      SUTM13      SUTM14      SUTM15
SUTM16      SUTM17      SUTM18      SUTM19      SUTM20
SUTM21      SUTM22      SUTM23      SUTM24      SUTM25
SUTM26      SUTM27      SUTM28      SUTM29      SUTM30
SUTM31      SUTM32      SUTM33      SUTM34      SUTM35
SUTM36      SUTM37      SUTM38      SUTM39      SUTM40
SUTM41      SUTM42      SUTM43      SUTM44      SUTM45
SUTM46      SUTM47      SUTM48      SUTM49      SUTM50
SUTM51      SUTM52      SUTM53      SUTM54      SUTM55
SUTM56      SUTM57      SUTM58      SUTM59      SUTM60

SPCS                           ER Mapper Code PCI Code
----                           -------------- --------
Alabama East                   TMALABEF       101
Alabama West                   TMALABWF       102
Alaska State Plane 1           OMALSK1M       5001
Alaska State Plane 2           TMALSK2M       5002
Alaska State Plane 3           TMALSK3M       5003
Alaska State Plane 4           TMALSK4M       5004
Alaska State Plane 5           TMALSK5M       5005
Alaska State Plane 6           TMALSK6M       5006
Alaska State Plane 7           TMALSK7M       5007
Alaska State Plane 8           TMALSK8M       5008
Alaska State Plane 9           TMALSK9M       5009
Arizona East                   TMARIZEF       201
Arizona Central                TMARIZCF       202
Arizona West                   TMARIZWF       203
Arkansas North                 LM2ARKNM       301
Arkansas South                 LM2ARKSM       302
California I                   LM2CAL1F       401
California II                  LM2CAL2F       402
California II                  LM2CAL3F       403
California II                  LM2CAL4F       404
California II                  LM2CAL5F       405
California II                  LM2CAL6F       406
California II                  LM2CAL7F       407
Colorado North                 LM2COLNF       501
Colorado Central               LM2COLCF       502
Colorado South                 LM2COLSF       503
Connecticut State              LM2CONNM       600
Deleware State                 TMDELWRF       700
Florida North                  LM2FLANF       903
Florida East                   TMFLRAEF       901
Florida West                   TMFLRAWF       902
Georgia East                   TMGEOREF       1001
Georgia West                   TMGEORWF       1002
Hawaii State Plane 1           TMHAWI1F       5101
Hawaii State Plane 2           TMHAWI2F       5102
Hawaii State Plane 3           TMHAWI3F       5103
Hawaii State Plane 4           TMHAWI4F       5104
Hawaii State Plane 5           TMHAWI5F       5105
Idaho East                     TMIDAEFT       1101
Idaho Central                  TMIDACFT       1102
Idaho West                     TMIDAWFT       1103
Illinois East                  TMILLEFT       1201
Illinois West                  TMILLWFT       1202
Indiana East                   TMINDEFT       1301
Indiana West                   TMINDWFT       1302
Iowa North                     LM2IOWNF       1401
Iowa South                     LM2IOWSF       1402
Kansas North (NAD27)           LM2KANNF       1501
Kansas North (NAD83)           LM2KANNM       1501
Kentucky North (NAD27)         LM2KYNFT       1601
Kentucky South (NAD83)         LM2KYSFT       1602
Louisiana North (NAD27)        LM2LANFT       1701
Louisiana North (NAD83)        LM2LANM        1701
Louisiana South (NAD27)        LM2LASFT       1702
Louisiana South (NAD83)        LM2LASM        1702
Louisiana OffShore             LM2LAOFT       1703
Maine East                     TMMAINEF       1801
Maine West                     TMMAINWF       1802
Maryland State                 LM2MARYF       1900
Massachusetts Mainland         LM2MASMF       2001
Massachusetts Island           LM2MASIF       2002
Michigan East (old)            TMMICHEF       2101
Michigan Central (old)         TMMICHCF       2102
Michigan West (old)            TMMICHWF       2103
Michigan North (current)       LM2MICNF       2111
Michigan Central (current)     LM2MICCF       2112
Michigan South (current)       LM2MICSF       2113
Minnesota North                LM2MINNF       2201
Minnesota Central              LM2MINCF       2202
Minnesota South                LM2MINSF       2203
Mississippi East (NAD27)       TMMISSEF       2301
Mississippi East (NAD83)       TMMISSEM       2301
Mississippi West (NAD27)       TMMISSWF       2302
Mississippi West (NAD83)       TMMISSWM       2302
Missouri East                  TMMISOEF       2401
Missouri Central               TMMISOCF       2402
Missouri West                  TMMISOWF       2403
Montana North                  LM2MTNFT       2501
Montana Central                LM2MTCFT       2502
Montana South                  LM2MTSFT       2503
Nebraska North                 LM2NEBNF       2601
Nebraska South                 LM2NEBSF       2602
Nevada East (NAD27)            TMNEVAEF       2701
Nevada East (NAD83)            TMNEVAEM       2701
Nevada Central (NAD27)         TMNEVACF       2702
Nevada Central (NAD83)         TMNEVACM       2702
Nevada West (NAD27)            TMNEVAWF       2703
Nevada West (NAD83)            TMNEVAWM       2703
New Hampshire                  TMNEWHFT       2800
New Jersey                     TMNEWJFT       2900
New Mexico East                TMNEWMEF       3001
New Mexico Central             TMNEWMCF       3002
New Mexico West                TMNEWMWF       3003
New York State East            TMNEWYEF       3101
New York State Central         TMNEWYCF       3102
New York State West            TMNEWYWF       3103
New York Long Island           LM2NEWYF       3104
North Carolina                 LM2NCAFT       3200
North Dakota North             LM2NDNFT       3301
North Dakota South             LM2NDSFT       3302
Ohio North                     LM2OHINF       3401
Ohio South                     LM2OHISF       3402
Oklahoma North                 LM2OKLNF       3501
Oklahoma South                 LM2OKLSF       3502
Oregon North                   LM2ORENF       3601
Oregon South                   LM2ORESF       3602
Pennsylvania North             LM2PANFT       3701
Pennsylvania South             LM2PANST       3702
Puerto Rico and Virgin Islands LM2PRV1F       5200
Rhode Island                   TMRHODIF       3800
South Carolina North           LM2SCNFT       3901
South Carolina South           LM2SCSFT       3902
South Dakota North             LM2SDNFT       4001
South Dakota South             LM2SDSFT       4002
Tennessee                      LM2TENNF       4100
Texas North                    LM2TXNF        4201
Texas North Central (NAD27)    LM2TXNCF       4202
Texas North Central (NAD83)    LM2TXNCM       4202
Texas Central (NAD27)          LM2TXCF        4203
Texas Central (NAD83)          LM2TXCM        4203
Texas South Central (NAD27)    LM2TXSCF       4204
Texas South Central (NAD83)    LM2TXSCM       4204
Texas South (NAD27)            LM2TXSF        4205
Texas South (NAD83)            LM2TXSM        4205
Utah North                     LM2UTHNF       4301
Utah Central                   LM2UTHCF       4302
Utah South                     LM2UTHSF       4303
Vermont                        TMVERMTF       4400
Virginia North                 LM2VIRNF       4501
Virginia South                 LM2VIRSF       4502
Washington North               LM2WSHNF       4601
Washington South               LM2WSHSF       4602
West Virginia North            LM2WVANF       4701
West Virginia South            LM2WVASF       4702
Wisconsin North                LM2WISNF       4801
Wisconsin Central              LM2WISCF       4802
Wisconsin South                LM2WISSF       4803
Wyoming East                   TMWYO1FT       4901
Wyoming East Central           TMWYO2FT       4902
Wyoming West Central           TMWYO3FT       4903
Wyoming West                   TMWYO4FT       4904


ER Mapper Rasters (ERS)

An ER Mapper Raster dataset is made up of two files: a header file, with an .ERS extension and a data file of the same basename with no extension. The GeoGateway library supports ER Mapper's Rasters for live linking, import and export.

The ER Mapper raster data file contains the data itself. The raster data is stored in a binary, Band-Interleaved-by-Line (BIL) format. The pixels' data type is defined in the accompanying header file. The data file name has no extension.

The ER Mapper dataset header file is an ASCII file describing the raster data in the data file. The dataset header file has the same base name as the data file it is describing, with the extension ".ers" added. For example, "Australia_DTM.ers" is a valid raster dataset header file name for the raster data file "Australia_DTM."

The entire header file holds information about the data source and is contained in the DatasetHeader block. There are two compulsory sub-blocks, the CoordinateSpace block (to define the coordinate space and location) and the RasterInfo block (to define the characteristics of the data in the accompanying data file). The RasterInfo block my contain a number of optional sub-blocks.

The following section discusses some of the information found in the dataset header file and what entries PCI's GeoGateway uses/supports.

       A DataType entry MUST exist and it MUST be "Raster".

       ByteOrder can be either "MSBFirst" (Most significant byte
               first) or "LSBFirst" (Least significant byte first).

       Datum can be "RAW" or one of the ER Mapper Supported Datums.
               If it is an unsupported datum, the Clarke 1866 datum
               is set by default.

       Projection can be "RAW" or one of the ER Mapper Supported
               Projections. If it is RAW or an unsupported projection,
               the projection defaults to METER by default.

       CoordinateType can be RAW, EN or LATLONG (notice there are
               no quotes for these entries). If it is RAW or EN
               (Easting/Northing), the coordinates in the header
               file will be interpreted as meters. If it is LATLONG,
               they will be interpreted as latitude and longitude
               expressed in degrees.

       Units can be expressed as "METERS" or an entry with "FOOT".
               All other entries are interpreted as meters, by default.

       CellType defines the data type of the pixels in the data file.

               Supported entries are:          Unsigned8BitInteger
                                                       Unsigned16BitInteger
                                                       Signed16BitInteger
                                                       IEEE4ByteReal

               Unsupported entries are:        Signed8BitInteger
                                                       Signed32BitInteger
                                                       Unsigned32BitInteger
                                                       IEEE8ByteReal

       NrOfLines, NrOfCellsPerLine and NrOfBands have integer values
               detailing number of lines, pixels and bands in the
               dataset.

       RegistrationCellX and RegistrationCellY hold the dataset
               X and Y (pixel/line) coordinates of the cell which
               corresponds to the RegistrationCoord block data. If
               they are not specified, the top left corner (0,0) is
               assumed to be the cell whose coordinates are provided
               as the Registration coordinates.

       The optional CellInfo block has two entries: the Xdimension
               and Ydimension. These identify the cell resolution.
               If they do not exist, the value 1 becomes the default.

       The optional RegistrationCoord block defines the location
               of the registration cell in the dataset. This block
               is not optional, however, if the CoordinateType is
               EN or LATLONG. The entries in the RegistrationCoord
               block will be identified as Eastings/Northings,
               MetersX/MetersY or Latitude/Longitude (in decimal
               degrees).

       Channel descriptions for the bands contained in an ER Mapper
               raster are read from the Value entries in the BandId
               blocks. Otherwise they are listed as "Contents not
               specified."

       If a HeaderOffset entry appears, its value is interpreted
               as the length (in bytes) of any header data found in
               the data file.

       The CoordinateSpace's Rotation value is currently ignored
               by PCI's GeoGateway.

       The RegionInfo, WarpControl and FFTInfo blocks are also
               ignored.


Supported ER Mapper Projections

PCI reads and applies the georeferencing information contained in the ECW file. ER Mapper's supported SPCS (State Plane Coordinate System), their UTM Metre projections and their Lambert1 and Lambert2 projections are fully supported in PCI products. The following is a comprehensive list of the ER Mapper projections that are supported:

ER Mapper Projection Codes
==========================

lambert1
--------
LM1ADEN     LM1AFNDX    LM1ALGND    LM1ALGSD    LM1BANG
LM1BLSEA    LM1BURMA    LM1CARIB    LM1CAUC     LM1COLC
LM1CORSE    LM1FRA1D    LM1FRA1G    LM1FRA2D    LM1FRA2G
LM1FRA3D    LM1FRA3G    LM1FRA4D    LM1FRA4G    LM1FRAND
LM1FRE1D    LM1FRE1G    LM1FRE2D    LM1FRE2G    LM1FRE3D
LM1FRE3G    LM1FRE4D    LM1FRE4G    LM1GREN1    LM1GRNOR

LM1GRSUD    LM1IND1     LM1IRAN     LM1IRAQ     LM1JAFT
LM1JAMTR    LM1KANG     LM1LEVD     LM1LEVG     LM1LIBS
LM1LIBYA    LM1MORND    LM1MORSD    LM1NEP1     LM1NEP2A
LM1NEP2B    LM1NPG      LM1PA2B     LM1PA2BY    LM1PAK1
LM1PAK1Y    LM1PAK2     LM1PAK2Y    LM1PB1D     LM1PB1G
LM1POL      LM1ROM      LM1SHAB     LM1SPAIN    LM1SPANM
LM1SYRSD    LM1SYRSG    LM1TUNND    LM1TUNSD    LM1TURK
LM1USSR

lambert2
--------
LM2AF113    LM2AF114    LM2AF72     LM2AF92     LM2AF93
LM2AF94     LM2AF95     LM2AFE      LM2AFSH     LM2ALG
LM2ARAB     LM2AREA1    LM2AREA2    LM2AREA3    LM2ARKNF
LM2ARKNM    LM2ARKSF    LM2ARKSM    LM2ASEAN    LM2ASIA
LM2AUST     LM2AZERB    LM2BAREN    LM2BELG     LM2BKSEA
LM2BLACK    LM2BLCKS    LM2NLKSE    LM2BNOR     LM2BOF
LM2BURMA    LM2CAL1F    LM2CAL2F    LM2CAL3F    LM2CAL4F
LM2CAL4M    LM2CAL5F    LM2CAL5M    LM2CAL6F    LM2CAL7F
LM2CAMER    LM2CAN      LM2CAN60    LM2CAN78    LM2CBRAZ
LM2CEGYP    LM2CFRAN    LM2CHBON    LM2CHECS    LM2CHEOF
LM2CHIN     LM2CHINA    LM2CHRUS    LM2CHYS     LM2COLCF
LM2COLNF    LM2COLSF    LM2COLUM    LM2COMAN    LM2CONNF
LM2CONNM    LM2CSPN     LM2EE       LM2EGYPT    LM2EUNDX
LM2EURO     LM2FKLDS    LM2FLANF    LM2FRANC    LM2GULF
LM2H6       LM2IND76    LM2IND77    LM2IND78    LM2IND96
LM2IND97    LM2IND98    LM2INDIA    LM2IOWNF    LM2IOWSF
LM2IRAM     LM2JEBCO    LM2JUNGB    LM2KALIM    LM2KANNF
LM2KANNM    LM2KYNFT    LM2KYNM     LM2KYSFT    LM2LANDS
LM2LANFT    LM2LANM     LM2LAOFT    LM2LASFT    LM2LASM
LM2MAINE    LM2MARYF    LM2MASIF    LM2MASIM    LM2MASMF
LM2ME       LM2ME1      LM2MEDIT    LM2MICCF    LM2MICNF
LM2MICSF    LM2MINCF    LM2MINNF    LM2MINSF    LM2MOCFT
LM2MON      LM2MONFT    LM2MOSFT    LM2MTCFT    LM2MTM
LM2MTNFT    LM2MTSFT    LM2NBRUN    LM2NCAFT    LM2NBSEA
LM2NDNFT    LM2NDNM     LM2NDSFT    LM2NEBM     LM2NEBNF
LM2NEBSF    LM2NEPAL    LM2NEWYF    LM2NFA      LM2NFB
LM2NHEM     LM2NSEA     LM2NZN      LM2NZS      LM2OHINF
LM2OHISF    LM2OKLNF    LM2OKLNM    LM2OKLSF    LM2OKLSM
LM2ORENF    LM2ONH25    LM2ORESF    LM2OSTER    LM2PANFT
LM2PASFT    LM2PRMB     LM2PRV1F    LM2PRV2F    LM2RUSS
LM2RUSS1    LM2RUSS2    LM2RUSS3    LM2RUSS4    LM2RUSS5
LM2RUSS6    LM2SCHIN    LM2SCHNS    LM2SCNFT    LM2SCSFT
LM2SDNFT    LM2SDSFT    LM2SEYCH    LM2SHAW     LM2SYRIA
LM2TAIW     LM2TARIM    LM2TENNF    LM2TIMAN    LM2TURK
LM2TURKG    LM2TURKY    LM2TXCF     LM2TXCM     LM2TXNCF
LM2TXNCM    LM2TXNF     LM2TXSCF    LM2TXSCM    LM2TXSF
LM2TXSM     LM2UKN      LM2USSR     LM2USSR1    LM2UTHCF
LM2UTHNF    LM2UTHSF    LM2VEN      LM2VENCN    LM2VENPC
LM2VIET     LM2VIRNF    LM2VIRSF    LM2WISCF    LM2WISNF
LM2WISSF    LM2WSHNF    LM2WSHSF    LM2WVANF    LM2WVASF

utm
---
NUTM01      NUTM02      NUTM03      NUTM04      NUTM05
NUTM06      NUTM07      NUTM08      NUTM09      NUTM10
NUTM11      NUTM12      NUTM13      NUTM14      NUTM15
NUTM16      NUTM17      NUTM18      NUTM19      NUTM20
NUTM21      NUTM22      NUTM23      NUTM24      NUTM25
NUTM26      NUTM27      NUTM28      NUTM29      NUTM30
NUTM31      NUTM32      NUTM33      NUTM34      NUTM35
NUTM36      NUTM37      NUTM38      NUTM39      NUTM40
NUTM41      NUTM42      NUTM43      NUTM44      NUTM45
NUTM46      NUTM47      NUTM48      NUTM49      NUTM50
NUTM51      NUTM52      NUTM53      NUTM54      NUTM55
NUTM56      NUTM57      NUTM58      NUTM59      NUTM60

SUTM01      SUTM02      SUTM03      SUTM04      SUTM05
SUTM06      SUTM07      SUTM08      SUTM09      SUTM10
SUTM11      SUTM12      SUTM13      SUTM14      SUTM15
SUTM16      SUTM17      SUTM18      SUTM19      SUTM20
SUTM21      SUTM22      SUTM23      SUTM24      SUTM25
SUTM26      SUTM27      SUTM28      SUTM29      SUTM30
SUTM31      SUTM32      SUTM33      SUTM34      SUTM35
SUTM36      SUTM37      SUTM38      SUTM39      SUTM40
SUTM41      SUTM42      SUTM43      SUTM44      SUTM45
SUTM46      SUTM47      SUTM48      SUTM49      SUTM50
SUTM51      SUTM52      SUTM53      SUTM54      SUTM55
SUTM56      SUTM57      SUTM58      SUTM59      SUTM60

SPCS                           ER Mapper Code PCI Code
----                           -------------- --------
Alabama East                   TMALABEF       101
Alabama West                   TMALABWF       102
Alaska State Plane 1           OMALSK1M       5001
Alaska State Plane 2           TMALSK2M       5002
Alaska State Plane 3           TMALSK3M       5003
Alaska State Plane 4           TMALSK4M       5004
Alaska State Plane 5           TMALSK5M       5005
Alaska State Plane 6           TMALSK6M       5006
Alaska State Plane 7           TMALSK7M       5007
Alaska State Plane 8           TMALSK8M       5008
Alaska State Plane 9           TMALSK9M       5009
Arizona East                   TMARIZEF       201
Arizona Central                TMARIZCF       202
Arizona West                   TMARIZWF       203
Arkansas North                 LM2ARKNM       301
Arkansas South                 LM2ARKSM       302
California I                   LM2CAL1F       401
California II                  LM2CAL2F       402
California II                  LM2CAL3F       403
California II                  LM2CAL4F       404
California II                  LM2CAL5F       405
California II                  LM2CAL6F       406
California II                  LM2CAL7F       407
Colorado North                 LM2COLNF       501
Colorado Central               LM2COLCF       502
Colorado South                 LM2COLSF       503
Connecticut State              LM2CONNM       600
Deleware State                 TMDELWRF       700
Florida North                  LM2FLANF       903
Florida East                   TMFLRAEF       901
Florida West                   TMFLRAWF       902
Georgia East                   TMGEOREF       1001
Georgia West                   TMGEORWF       1002
Hawaii State Plane 1           TMHAWI1F       5101
Hawaii State Plane 2           TMHAWI2F       5102
Hawaii State Plane 3           TMHAWI3F       5103
Hawaii State Plane 4           TMHAWI4F       5104
Hawaii State Plane 5           TMHAWI5F       5105
Idaho East                     TMIDAEFT       1101
Idaho Central                  TMIDACFT       1102
Idaho West                     TMIDAWFT       1103
Illinois East                  TMILLEFT       1201
Illinois West                  TMILLWFT       1202
Indiana East                   TMINDEFT       1301
Indiana West                   TMINDWFT       1302
Iowa North                     LM2IOWNF       1401
Iowa South                     LM2IOWSF       1402
Kansas North (NAD27)           LM2KANNF       1501
Kansas North (NAD83)           LM2KANNM       1501
Kentucky North (NAD27)         LM2KYNFT       1601
Kentucky South (NAD83)         LM2KYSFT       1602
Louisiana North (NAD27)        LM2LANFT       1701
Louisiana North (NAD83)        LM2LANM        1701
Louisiana South (NAD27)        LM2LASFT       1702
Louisiana South (NAD83)        LM2LASM        1702
Louisiana OffShore             LM2LAOFT       1703
Maine East                     TMMAINEF       1801
Maine West                     TMMAINWF       1802
Maryland State                 LM2MARYF       1900
Massachusetts Mainland         LM2MASMF       2001
Massachusetts Island           LM2MASIF       2002
Michigan East (old)            TMMICHEF       2101
Michigan Central (old)         TMMICHCF       2102
Michigan West (old)            TMMICHWF       2103
Michigan North (current)       LM2MICNF       2111
Michigan Central (current)     LM2MICCF       2112
Michigan South (current)       LM2MICSF       2113
Minnesota North                LM2MINNF       2201
Minnesota Central              LM2MINCF       2202
Minnesota South                LM2MINSF       2203
Mississippi East (NAD27)       TMMISSEF       2301
Mississippi East (NAD83)       TMMISSEM       2301
Mississippi West (NAD27)       TMMISSWF       2302
Mississippi West (NAD83)       TMMISSWM       2302
Missouri East                  TMMISOEF       2401
Missouri Central               TMMISOCF       2402
Missouri West                  TMMISOWF       2403
Montana North                  LM2MTNFT       2501
Montana Central                LM2MTCFT       2502
Montana South                  LM2MTSFT       2503
Nebraska North                 LM2NEBNF       2601
Nebraska South                 LM2NEBSF       2602
Nevada East (NAD27)            TMNEVAEF       2701
Nevada East (NAD83)            TMNEVAEM       2701
Nevada Central (NAD27)         TMNEVACF       2702
Nevada Central (NAD83)         TMNEVACM       2702
Nevada West (NAD27)            TMNEVAWF       2703
Nevada West (NAD83)            TMNEVAWM       2703
New Hampshire                  TMNEWHFT       2800
New Jersey                     TMNEWJFT       2900
New Mexico East                TMNEWMEF       3001
New Mexico Central             TMNEWMCF       3002
New Mexico West                TMNEWMWF       3003
New York State East            TMNEWYEF       3101
New York State Central         TMNEWYCF       3102
New York State West            TMNEWYWF       3103
New York Long Island           LM2NEWYF       3104
North Carolina                 LM2NCAFT       3200
North Dakota North             LM2NDNFT       3301
North Dakota South             LM2NDSFT       3302
Ohio North                     LM2OHINF       3401
Ohio South                     LM2OHISF       3402
Oklahoma North                 LM2OKLNF       3501
Oklahoma South                 LM2OKLSF       3502
Oregon North                   LM2ORENF       3601
Oregon South                   LM2ORESF       3602
Pennsylvania North             LM2PANFT       3701
Pennsylvania South             LM2PANST       3702
Puerto Rico and Virgin Islands LM2PRV1F       5200
Rhode Island                   TMRHODIF       3800
South Carolina North           LM2SCNFT       3901
South Carolina South           LM2SCSFT       3902
South Dakota North             LM2SDNFT       4001
South Dakota South             LM2SDSFT       4002
Tennessee                      LM2TENNF       4100
Texas North                    LM2TXNF        4201
Texas North Central (NAD27)    LM2TXNCF       4202
Texas North Central (NAD83)    LM2TXNCM       4202
Texas Central (NAD27)          LM2TXCF        4203
Texas Central (NAD83)          LM2TXCM        4203
Texas South Central (NAD27)    LM2TXSCF       4204
Texas South Central (NAD83)    LM2TXSCM       4204
Texas South (NAD27)            LM2TXSF        4205
Texas South (NAD83)            LM2TXSM        4205
Utah North                     LM2UTHNF       4301
Utah Central                   LM2UTHCF       4302
Utah South                     LM2UTHSF       4303
Vermont                        TMVERMTF       4400
Virginia North                 LM2VIRNF       4501
Virginia South                 LM2VIRSF       4502
Washington North               LM2WSHNF       4601
Washington South               LM2WSHSF       4602
West Virginia North            LM2WVANF       4701
West Virginia South            LM2WVASF       4702
Wisconsin North                LM2WISNF       4801
Wisconsin Central              LM2WISCF       4802
Wisconsin South                LM2WISSF       4803
Wyoming East                   TMWYO1FT       4901
Wyoming East Central           TMWYO2FT       4902
Wyoming West Central           TMWYO3FT       4903
Wyoming West                   TMWYO4FT       4904


EOSAT CD-ROM

EOSAT Fast Format is a tape format that has been extended to be used as a CDROM distribution format. GeoGateway library support has been added for this format as distributed by EOSAT, RADARSAT, and the Indian Remote Sensing Centre. Revisions A, B, and C of EOSAT Fast Format should be supported.

The directory and naming conventions for EOSAT Fast Format CDROMs may vary, however, the GeoGateway library is only able to understand two file naming conventions. It may be possible to read EOSAT Fast Format CDROMs from other sources if the files are renamed to match one of the following conventions.

  • RADARSAT CDROMs typically name the files as follows:
  /cdrom/SCENE01/VOLD_01.DAT   <--- Select this file.
  /cdrom/SCENE01/BAND_01.DAT
  /cdrom/SCENE01/BAND_02.DAT
  /cdrom/SCENE01/BAND_03.DAT
  • EOSAT and Indian CDROMs typically name the files as follows:
  /cdrom/SAMPLES/LISS1/HEADER.DAT   <--- Select this file
  /cdrom/SAMPLES/LISS1/BAND1.DAT
  /cdrom/SAMPLES/LISS1/BAND2.DAT
  /cdrom/SAMPLES/LISS1/BAND3.DAT

Georeferencing information may be extracted for some precision geocoded products. All EOSAT Fast Format datasets should contain a GCP segment with five points tying down the image corner points and centre. These are suitable for an approximate image correction with GCPWorks or REG. The contents of the header file are carried with the dataset as a test segment for later review, if required.

There is currently no support for generating EOSAT Fast Format datasets with EASI/PACE.

The USGS is now distributing landsat products in NDF (NLAPS Data Format), which is also a supported format.

See Also


ELAS ZSoft Raster (ELAS)

The ELAS file format is a raster file format used with some scanners. One such scanner is DAEDALUS 1268 is manufactured by DAEDALUS ENTERPRISES INCORPORATED (Annarbor - Michigan USA).

"E.L.A.S. : Earth Resources Laboratory Applications Software is a Geobased Information System it is designed for analyzing and processing digital imagery data, such as those collected by multispectral scanners or digitized from maps."

Geogateway supports the image variants which have 8 bits per pixel.

Export of ELAS files is not supported.


ENVI Raster (.hdr)

ENVI raster files (.hdr) are supported by GeoGateway for import, update, and export. ENVI datasets consist of two files, the header file (with the extension .hdr), and the image file (same basename as .hdr file, but no fixed extension). The user should always select the .hdr file to reference the dataset.

Import, and export support includes limited support for projections (Lat/Long, State Plane, and UTM), and limited support for datums/ellipsoids (WGS *, NAD27, and NAD83). Complex projections are imported and exported as generic METREs.

Only raster types 1, 2, and 4 (8bit unsigned, 16bit signed, and 32bit floating) are supported. Unsupported raster data types includes 32bit integer, 64 bit floating, and complex rasters.

At this time class name and colour map information is not read from, nor written to ENVI files though it is expected that this will be added in the future.

Export of ENVI files is supported. These files are exported with a file type of "NVI". The exported files can have any number of channels, and may be any PCI supported channel type. Georeferencing information will be written to the ENVI .hdr file with the limitations mentioned above. Metadata, history and georeferencing information suitable for use with GeoGateway applications will be stored in a .aux file, but this is not utilized by ENVI.


Envisat

GDB support AATSR, ASAR and MERIS sensors.

See Also

AATSR, ASAR, MERIS


Erdas Imagine (.img)

Erdas Imagine (.img) files are supported by the GeoGateway library for import, update and export.

All data types are supported for import but layers types with no corresponding GeoGateway type are converted to the most appropriate type. Any 1-bit image layers are promoted to 8-bit via GeoGateway, not a bitmap segment as might be expected.

Most georeferencing information is supported for import and export; however, the identity of many datums may be lost. As well, a few Erdas projections are not supported by GeoGateway.

Imagine pseudo-colour tables are supported on import and export. However, GCPs and other auxilary information in Erdas files are not translated at this time.

Export of Erdas Imagine files is supported with a type of "IMG". Any number of bands may be exported, and all GeoGateway image data types are supported on export to Erdas format. PCTs may also be exported, but note that the first PCT exported will be applied to the first band exported, the second to the second and so forth.

Erdas Imagine files produced by GeoGateway contain a minimum superstructure. They do not include overviews, histogram or other statistics information, and therefore they may not behave exactly the same as images generated within Imagine.

Erdas Imagine supports files that are greater than 2 Gigabytes in size using the .ige imagery file. GDB supports the .ige file for import and export.

The option "1bit", "2bit" and "4bit" is used to specify output data type.

See Also


Erdas .GIS And .LAN

Erdas version 7.4 .GIS and .LAN image files are supported by the GeoGateway library. In fact, some files earlier than version 7.4 are also supported, but the new version 8.0 files may not be supported. Both 8-bit, and 16-bit unsigned Erdas files are supported; however, 4-bit files are not supported. Limited support for reading georeferencing information exists, however, UTM zones and other detailed projection information is lost on import or export. Bounds are properly preserved.

Only the .GIS or .LAN files are read by the GeoGateway library. None of the auxiliary or trailer files are read or generated.

Export of Erdas .GIS and .LAN files is supported. These files are exported with a type of "ERD".

The Erdas file may contain any number of image channels of either eight bit or sixteen bit unsigned data types.

Georeferencing information will be written to the Erdas file if it is Long/Lat or UTM. No other data types such as PCTs, or LUTs can be written.

See Also


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

Excel (.xls)

See DAO.


Generic ASCII Vector (GAV)

GAV is a generic ASCII vector format that allows you to define and use an ASCII vector database. GAV is supported by the GeoGateway library for import and export.

The GAV database name has the following format:

 GAV:"Name of ASCII data file" "Name of ASCII schema file defining data file".

For example:

A GAV database having a data file named "test" and a schema file named "test.gav" will have the name "GAV:test test.gav".

A simple example of a GAV data file is, having <x,y,z> data in a file, one set per line. Specifically, if the data file "test" has two points <1,2,3> and <4,5,6>, it will look like the following:

       1       2       3
       4       5       6

The schema file "test.gav" for the above format will look like the following:

  GAV
  CATEGORY: VARIABLE
  NAME: SIMPLE LineXYZ - Tabular Variable
  OFFSET(ROWS): 0
  SEPARATOR_CHARS: " \t"
  COMMENT_CHARS: "#"
  DATA: TYPE(X) POSITION(1)
  DATA: TYPE(Y) POSITION(2)
  DATA: TYPE(Z) POSITION(3)

Another way to specify a GAV database name is to use the following format:

  GAV:"Name of ASCII data file"

In this case, the schema file is taken to be ".gav" in the current directory.

Export of Generic ASCII Vector files is supported. These files are generated with a type of "GAV". There are no options on export. The data file is semicolon separated variable length records.

Generic ASCII Vector files can only hold one segment.


GAV Introduction

GAV is a Generic ASCII Vector format that allows you to define and use a database of vectors stored in an ASCII text file. The GAV format supports vector point data, as well as attribute (or table) data. It does not support files having more than one point definition per line. GAV is a GDB supported format.

A GAV database is specified using the following syntax:

    data_file [schema_file]

where, data_file refers to the name of the text file containing the vector data, and the optional schema_file refers to the name of a second text file defining how the vector data is laid out in the data file. The schema file will most likely have to be created by the user.

Note: The schema file is optional only if it has the same basename as the data file, it has a ".gav" extension, and it is located in the same directory as the data file.

Examples:

A GAV database with a data file named "data.txt" and a schema file named "schema.gav" is specified as follows:

data.txt,schema.gav

A GAV database with a data file named "xyz.txt" and a schema file named "xyz.gav" can be specified in either one of the following ways:

xyz.txt,xyz.gav
xyz.txt

If the data file or the schema file are not located in the working directory, the files must be specified with full paths.

/usr/fred/data.txt,/usr/fred/schema.gav        (Unix)
c:\home\fred\data.txt,c:\home\fred\schema.gav  (Windows)

See Also


GAV Schema File

Each line in a GAV schema file begins with a "token" or a "descriptor". These are special keywords used in defining the format of the data. The first line of a schema file must contain only the token "GAV". This identifies the file as a GAV schema file. The remaining lines in the schema file describe the format of the data in the GAV data file.

A GAV schema file can contain comments. Comment lines begin with an exclamation mark (!) character. Comment lines and blank lines are ignored.

The following is a list of GAV descriptors:

    NAME
    CATEGORY
    OFFSET
    SEPARATOR_CHAR
    SEPARATOR_CHARS
    SEPARATORCHARS_ASONE
    HAS_COORDFIELD
    COMMENT_CHAR
    COMMENT_CHARS
    MAPUNITS
    METADATA
    METADATA_SEPARATOR
    LAYER_END
    LAYER_END_REUSE
    DATA
    ROWS

The descriptors SEPARATOR_CHAR and SEPARATOR_CHARS are equivalent, as are COMMENT_CHAR AND COMMENT_CHARS.

GAV descriptors are case insensitive.


NAME

The NAME descriptor assigns a name to the database. This descriptor is for information only.

Example:

    NAME: Simple XYZ data

This specifies the name of the database to be "Simple XYZ data".


CATEGORY

The CATEGORY descriptor defines the format or structure of the data in a GAV data file. Currently, two formats are supported: VARIABLE and FIXED.

To identify a GAV data file as belonging to the variable category, use the following line in the GAV schema file:

    CATEGORY: VARIABLE

To identify a GAV data file as belonging to the fixed category, use the following line in the GAV schema file:

    CATEGORY: FIXED


VARIABLE

A GAV data file of variable category has one record per line (i.e., a record is terminated with a new-line character), and each data field in a record is separated by one or more separator characters as specified by the SEPARATOR_CHARS descriptor.

For example, the following lines could be a GAV data file of variable category, with separator characters being the space character ( ) and the comma (,).

    1 10,10 1000, 6 4
    2 10 20 1020  5 2
    3 10 30 1015  2 0

Individual fields in this category are accessed according to their position in the record. Therefore, in the example above, the values 1000, 1020, and 1015 are in the fourth position of each record.

Example:

A simple variable GAV schema file might look like this:

    GAV
    NAME: SIMPLE XYZ - Variable
    CATEGORY: VARIABLE
    !
    !    The following lines contain category specific information for
    !    variable format files.
    !
    OFFSET(ROWS): 0
    SEPARATOR_CHARS:" \t,"
    COMMENT_CHARS:"#"
    DATA: TYPE(INTEGER) ATTRIBUTE(Line|Line) POSITION(1)
    DATA: TYPE(X)  POSITION(2)
    DATA: TYPE(Y)  POSITION(3)
    DATA: TYPE(Z)  POSITION(4)

The corresponding GAV data file might look like this:

    1 10,10 1000, 6 4
    1 10 20 1020 5 2
    100 10 30 1015 2 0

This would produce the points (10,10,1000), (10,20,1020), and (10,30,1015). Notice that the separator characters are defined in this schema to be spaces, tabs, or commas. Notice also that the extra data on the end of each record is ignored.


FIXED

A GAV data file of fixed category has one record per line (i.e., a record is terminated with a new-line character), and each data field in a record is sequential, without separation.

For example, the following lines could be a GAV data file of fixed category.

    00641000300604
    00551000200502
    00720000150200

Individual fields in this category are accessed according to their columnar position and width in the record. Therefore, the values 64, 55, and 72 are accessed starting in column three (3) with a field width of two (2) digits.

Example:

A simple fixed GAV schema file might look like this:

    GAV
    NAME: SIMPLE XYZ - Fixed
    CATEGORY: FIXED
    !
    !    The following lines contain category specific information for
    !    fixed format files.
    !
    OFFSET(ROWS): 0
    COMMENT_CHARS:"#"
    DATA: TYPE(INTEGER) ATTRIBUTE(Line|Line) COLUMNS(1,5)
    DATA: TYPE(X)  COLUMNS(6,5)
    DATA: TYPE(Y)  COLUMNS(11,5)
    DATA: TYPE(Z)  COLUMNS(16,5)

The corresponding GAV data file might look like this:

    000010001000010010000604
    000010001000020010200502
    001000001000030010150200

This file would produce the points (00010,00010,01000), (00010,00020,01020), and (00010,00030,01015). Notice that the extra data on the end of each record is ignored.


OFFSET

The OFFSET descriptor specifies the number of lines to be skipped from the top of the GAV data file. Two types of offset are supported: BYTES and ROWS.

BYTES is used to specify the number of bytes or characters to be skipped from the start of the file.

ROWS is used to specify the number of rows or lines to be skipped from the start of the file.

Example:

You have a data file containing the following information.

    1 3 7 2 4 7
    2 9 9
    5 1 6
    1 3 2
    1 4 6

If you want to skip the first three values (1, 3, 7), then use the following offset.

OFFSET(BYTES):6

If you want to skip the first line, then use the following offset.

OFFSET(ROWS):1


SEPARATOR_CHARS

The SEPARATOR_CHARS descriptor defines the characters to use as field separators. Separator characters are defined within a pair of double quote (") characters. When a double quote is used as a separator character, it must be preceded by a backslash (\) character. Thus, \", designates " as a separator character. A tab is denoted by \t; a backslash is denoted by \\.

The SEPARATOR_CHAR descriptor is the same as the SEPARATOR_CHARS descriptor.

Examples:

       GAV data file   GAV schema file entry
       _____________   _____________________

    (a)    1 2 3           SEPARATOR_CHARS: " "
           2 3 4
           3 4 5

    (b)    1/2\3           SEPARATOR_CHARS: "/\\"
        2/3/4
        3\4\5

    (c)    1 2	3          SEPARATOR_CHARS: " \t,"
        2,3 4
           3   4,5

    (d)    1'2"3'          SEPARATOR_CHARS: "'\""
          2'3"4'
       3'4"5'

Example (a) above, specifies the space character as a separator character.

Example (b) specifies the forward slash (/) and backward slash (\) as separator characters.

Example (c) specifies the space, tab, and comma (,) characters as separator characters.

Example (d) specifies the single forward quote ('), and the double quote (") as separator characters.


SEPARATOR_CHARS_ASONE

The SEPARATORCHARS_ASONE descriptor defines the way of using characters that as field separators. when user input ascii table, if this flag set to TRUE, we will treat consecutive delimiters as one. if this flag set to FALSE, we will treat consecutive delimiters separably.

Examples:

           GAV data file   GAV schema file entry
       _____________   _____________________

           1/\\2\3           SEPARATOR_CHARS: "/\\"

       GAV schema file entry		Result
       _____________________		__________________

       SEPARATORCHARS_ASONE:1		Column: 1,2,3

       SEPARATORCHARS_ASONE:0		Column: 1,_,_,2,3


HAS_COORDFIELD

The HAS_COORDFIELD descriptor defines the way of adding coordinate to attribute table. when user input ascii table, if this flag set to TRUE, after we add Type(X) data, we will add one more attribute data line that use same data position( or column ), this case gav will not check reused position ( or overlap ), otherwise we can not repeatedly use data.


COMMENT_CHARS

The COMMENT_CHARS descriptor defines the characters used as comment indicators, in addition to the exclamation mark (!). These are defined in the same manner as the SEPARATOR_CHARS.

The COMMENT_CHAR descriptor is the same as the COMMENT_CHARS descriptor.

Example:

    GAV data file               GAV schema file entry
    _____________               _____________________

    ! --- GAV Data ---          COMMENT_CHARS: "#@"
    # This file contains only
    # X,Y,Z data.

    @ Start of data:
    1 2 3
    2 3 4
    3 4 5

This example shows comment lines in the data file indicated with the default exclamation mark (!), the pound (#) character, and the at (@) character.

The COMMENT_CHARS descriptor in the schema file defines the latter two as acceptable comment characters.


MAPUNITS

The MAPUNITS descriptor defines the map unit of a data file. Only simple map units such as "METRE", "UTM", "LONG", etc., are supported. If no MAPUNITS descriptor is specified, the map unit of the data file is defaulted to "METRE".

The MAPUNITS descriptor uses the following syntax:

  MAPUNITS = "map_units"

where, map_units is the text defining the map units. The map units text must always be enclosed in double quotes.

Example:

  MAPUNITS = "UTM 20 E000"


DATA

The DATA descriptor defines what a data field is, how it should be read/written, and where it should be placed. Several sub-descriptors are used to define a field's data type, attribute names, positions or columns, and precision.

The sub-descriptors are as follows:

  • TYPE
  • ATTRIBUTE
  • POSITION
  • COLUMN
  • COLUMNS
  • PRECISION

The sub-descriptors COLUMN and COLUMNS are equivalent.

For each data field, there is one DATA descriptor, followed by sub- descriptors, which define the type and location of the data field all on one line. Sub-descriptors are separated by spaces or commas. A data field may be a coordinate (one of X, Y, or Z) or an attribute.

Examples:

    DATA: TYPE(X), COLUMNS(6,5)
    DATA: TYPE(Y), COLUMNS(16-19)

    DATA: TYPE(STRING) ATTRIBUTE(Class)     POSITION(4)
    DATA: TYPE(FLOAT)  ATTRIBUTE(Elevation) POSITION(6)


TYPE

The TYPE sub-descriptor defines the data type of a field. Currently supported types are FLOAT, DOUBLE, INTEGER, STRING, X, Y, and Z. This sub-descriptor is usually used in conjunction with the POSITION sub-descriptor.

    FLOAT    = single precision real number
    DOUBLE   = double precision real number
    INTEGER  = positive/negative whole number
    STRING   = text

X, Y, Z are recognized as special vector attributes of type DOUBLE.

Example:

    GAV Data File               GAV Schema File
    _____________               _______________

    70.2 62.5 31.8 valley       GAV
    95.1 47.0 39.2 cliff        CATEGORY: VARIABLE
    82.4 58.8 32.5 valley       SEPARATOR_CHARS: " "
    79.3 61.6 33.0 valley       DATA: TYPE(X) POSITION(1)
    81.8 55.2 34.8 cliff        DATA: TYPE(Y) POSITION(2)
                                DATA: TYPE(Z) POSITION(3)
                                DATA: TYPE(STRING) ATTRIBUTE(Class) POSITION(4)

    Resulting Records (X, Y, Z, Class)
    __________________________________

    (70.2, 62.5, 31.8, "valley")
    (95.1, 47.0, 39.2, "cliff")
    (82.4, 58.8, 32.5, "valley")
    (79.3, 61.6, 33.0, "valley")
    (81.8, 55.2, 34.8, "cliff")

In this example, the fields in each record represent, respectively, x-position, y-position, elevation (z-position), and a class to which the point belongs. These values are interpreted as X, Y, Z vector attributes, and a text (string) attribute by the name of "Class".


ATTRIBUTE

The ATTRIBUTE sub-descriptor defines the attribute name of a data element and description of a data(name|desc). This sub-descriptor is usually used in conjunction with the TYPE and POSITION sub-descriptors.

Example:

    GAV Data File       GAV Schema File
    _____________       _______________

    79.351 1 mountain   GAV
    45.447 2 mountain   CATEGORY: VARIABLE
    28.235 3 mountain   SEPARATOR_CHARS: " "
    32.589 4 field      DATA: TYPE(DOUBLE)  ATTRIBUTE(Length|Length) POSITION(1)
    19.326 5 field      DATA: TYPE(INTEGER) ATTRIBUTE(ID|identify) POSITION(2)
            DATA: TYPE(STRING)  ATTRIBUTE(Region|Region) POSITION(3)

    Resulting Records (Length, ContourID, Region)
    _____________________________________________

    (79.351, 1, "mountain")
    (45.447, 2, "mountain")
    (28.235, 3, "mountain")
    (32.589, 4, "field")
    (19.326, 5, "field")

In this example, the fields in each record represent the following attributes associated with a set of contours: the length of the contour, the contour's ID number, and the region in which the contour lies.


POSITION

The POSITION sub-descriptor defines the token position of a data element. The first available position in a GAV data file is one. POSITION sub-descriptors are only used in GAV schema files of the VARIABLE category. This sub-descriptor is usually used in conjunction with the TYPE sub-descriptor.

Example:

    GAV Data File       GAV Schema File
    _____________       _______________

    70 62 31            GAV
    95 47 39            CATEGORY: VARIABLE
    82 58 32            SEPARATOR_CHARS: " "
    79 61 33            DATA: TYPE(X) POSITION(2)
    81 55 34            DATA: TYPE(Y) POSITION(3)
                        DATA: TYPE(Z) POSITION(1)

    Resulting Records (X, Y, Z)
    ___________________________

    (62, 31, 70)
    (47, 39, 95)
    (58, 32, 82)
    (61, 33, 79)
    (55, 34, 81)

In this example, the fields in one record of the data file represent elevation (z-position), x-position, and y-position, respectively. Thus, the schema file assigns the fields in positions two (2) and three (3) of each record to the special vector attribute types X and Y, and the field in position one (1) to Z.


COLUMNS

THE COLUMN(START-END) or COLUMN(START,WIDTH) sub-descriptor defines the data columns occupied by a data element. The first available column in a GAV data file is one. COLUMN sub-descriptors are only used in GAV schema files of the FIXED category.

The START-END defines an inclusive range, whereas, START,WIDTH defines an initial column and width. For example: COLUMN(1,5) and COLUMN(1-5) are equivalent, and so are COLUMN(10,5) and COLUMN(10-14).

Example:

    GAV Data File               GAV Schema File
    _____________               _______________

    000010001000010010000604    GAV
    000010001100020010200502    CATEGORY: FIXED
    001000001200030010150200    DATA: TYPE(X) COLUMNS(6,5)
                                DATA: TYPE(Y) COLUMNS(11,5)
                                DATA: TYPE(Z) COLUMNS(16-19)

    Resulting Records (X, Y, Z)
    ___________________________

    (10, 10, 1000)
    (11, 20, 1020)
    (12, 30, 1015)


PRECISION

The PRECISION sub-descriptor defines the precision of a data element having type FLOAT or DOUBLE.


METADATA

Specifies the number of rows or bytes of metadata in the header of the data. Only one form of the METADATA keyword should be used.

Example:

    METADATA(ROWS): 58
    METADATA(BYTES): 100


ROWS

Specifies the number of rows of data in the layer that follows. This may be less than the number of rows in the data file, if there are empty or non-data rows.

Example:

    ROWS: 1289


METADATA_SEPARATOR

Specifies the string that separates the name and value in the metadata name-value pairs.

Example:

    METADATA_SEPARATOR: "=="


LAYER_END

String that means the current layer is at an end.

Example:

    LAYER_END: "Number_of_header_lines"


LAYER_END_REUSE

Having found the string for the LAYER_END, do we re-use this row as part of the next layer or not.

Example:

    LAYER_END_REUSE: TRUE


FIMPORT Example (For EASI/PACE)

Import a GAV data file named "points.txt" with a schema file named "xyz.gav" to a PCIDSK file named "out.pix", using FIMPORT.

  EASI>FILI="GAV:points.txt xyz.gav"
  EASI>FILO="out.pix"
  EASI>RUN FIMPORT

The schema file "xyz.gav" contains the following:

  GAV
  NAME: SIMPLE XYZ - Variable
  CATEGORY: VARIABLE
  !
  !    The following lines contain category specific information for
  !    variable format files.
  !
  OFFSET(ROWS): 0
  SEPARATOR_CHARS:" \t,"
  COMMENT_CHARS:"#"
  DATA: TYPE(X)  POSITION(1)
  DATA: TYPE(Y)  POSITION(2)
  DATA: TYPE(Z)  POSITION(3)

The data file "points.txt" contains the following data:

   455     2    286
   974     2    551
     5     4     66
   750     5    351
    38    13     83
   611    19    291
   521    21    317
   700    26    324
   964    26    523
   613    29    295
   386    30    390
   312    31    199
   808    34    446
    ...

Fimport creates a PCIDSK file containing the GAV data.


Graphics Interchange Format (GIF)

Most common formats of GIF are supported for reading by GeoGateway including GIF87A and GIF89A files. As well, export to GIF format is supported. GIF format is a popular file format originally produced by CompuServe (tm). It is one of two formats (along with JPEG) common used on the World Wide Web.

GIF files are always represented as one raster channel, with a pseudocolour table. GIF files do not have any inherent concept of georeferencing. Comments, and other extensions to the GIF format are ignored.

Export of GIF files is supported. These files are exported with a type of "GIF". The exported image can only have one channel, and a pseudocolor table. If no pseudocolor table is provided during the export then a linear greyscale table will be used. Georeferencing, and metadata will be saved in an associated .aux file, but this will only be used by other PCI applications.

GIF format does not have any options at this time. At this time it is not possible to produce "interlaced", or progressively displayed GIF files.

In order to save a 24-bit image to a GIF file it is necessary to first convert the image to an 8-bit pseudocolored image. Within EASI/PACE this can be accomplished using the CMPRSS8 or related programs.

PCI would like to thank John Bradley, author of the XV image viewer, from which PCI's GIF translator was derived. PCI would also like to thank Patrick J. Naughton, Michael Mauldin, David Rowley, Spencer W. Thomas, Jim McKie, Steve Davies, Ken Turkowski, James A Woods, and Joe Orost who contributed to the GIF translator within XV.


GRASS Raster/Vector (GRS)

GRASS is a public domain raster/vector GIS produced by the U.S. government. GRASS dig (vector) files, as well as cell (raster) files are supported by the GeoGateway library for read and write operations.

GRASS filenames may be specified in one of two ways:

  1. If there is a .grassrc file in the user's home directory, a simple filename may be given. The file will then be placed in the correct layer for the file.
  2. If the .grassrc is not present, the user must specify a path along with the filename.

For vector files specified with neither a full path name nor a .grassrc, the dig (binary) version of the vector file will be read from or written to, before any ASCII file. To use an ASCII vector file, a path name which includes a dig_ascii directory must be specified.

The dig_plus file is not modified when a binary file is written to. The user will have to use the grass program v.support to update the dig_plus file.

When GRASS vectors are loaded, both Line and Area arcs are read in as polylines. The dig_att file is also read and processed. Each line attribute is associated with its unique line arc. Area attributes are read in as vector points with an attribute. Area arcs will have an assigned attribute of 0. No attempt is made to assign area attributes to their particular AREA arcs. Georeferencing bounds are imported for vector layers, but the correct georeferencing system is only selected for UTM. All others are mapped to METRE.

Export of GRASS files is supported. These files are exported with a type of "GRS".

Only uncompressed 8-bit, and 16-bit raster layers can be exported, and each raster layer may only contain one channel of imagery.

When GRASS files are written, those lines read in as line arcs or area arcs, are written out as lines or arcs respectively. Added lines are treated as line arcs. Added points will be written out as degenerate line arcs. Points that were read in as AREA attributes will not be written. These points will be written out only to the dig_att file.

The non-zero attribute of lines will be written out to the dig_att file. The coordinate associated with the attribute will be the midpoint between the first two vertices in the arc ( (P1+P2)/2 ).

Any attributes read in as AREA attributes will be output, unchanged, to the dig_att file.

GRASS files must be placed in the correct location within a GRASS directory tree. The path provided should be for a file in the "cell" or "cellhd" directory for raster output. If a .grassrc is present in the users home directory it should be possible to specify a layer name without a fully specified path.

For vectors the path provided for the output file will determine the type of file that is written out. Paths which include a "dig" directory in the path will result in a binary file, and paths which include "dig_ascii" will produce an ASCII file. In both cases, the attribute file will be written to the "dig_att" directory.

To write out grass format data when an existing GRASS directory tree does not exist, it is necessary to have a cell, and cellhd directory for rasters, or a dig, dig_att and dig_ascii directory for vectors.

For example, to export vector data in data/test.pix to binary GRS format, create two subdirectories: data/dig and data/dig_att. Then choose data/dig/test.grs as the export file. The attributes will be created in data/dig_att/test.grs.


Geosoft GRID File - Binary (GGF)

The Geosoft GRID file (Version 2.0) (*.grd or *.ggf) is supported for import and export by the GeoGateway library. GGF format is a binary raster format.

Only one channel will exist in a GGF file, therefore the format will not be used for multispectral imagery. Geosoft GRID files are always reported as having a channel type of 32R even though within the file they may be any of the traditional data types.

Georeferencing is read and written for GGF files. Once a GGF file is read, the georeferencing units may have to be changed from "METRE" to more appropriate units.

Only image data having a top-to-bottom orientation (sense = 1 and sense = -1) and zero rotation are supported. If the #SENSE (orientation) value in the file is not one of these values, a warning will be issued. The user can use the ImageWorks Transform tool, or the MIRROR PACE program to correct the orientation of unsupported #SENSE images.

Export of Geosoft Version 2.00 binary files is supported. These files are exported with a type of "GGF". They can only hold one channel.

See Also

GXF, PLT


Geosoft GRID File - ASCII (GXF)

GXF Version 2.00 ASCII image file format is supported for import and export by the GeoGateway library. GXF format is a simple ASCII formatted raster. Only one channel will exist in a GXF file, therefore the format will not be used for multispectral imagery. Only uncompressed image data is supported.

Georeferencing is read and written for GXF files. Once a GXF file is read, the georeferencing units may have to be changed from "METRE" to more appropriate units.

Only image data having left to right scanlines, starting from the bottom or top of the target image (sense = 1 and sense = -1), are supported fully. If the #SENSE (orientation) value in the file is not one of these values, a warning will be issued. The user can use the ImageWorks Transform tool, or the MIRROR PACE program to correct the orientation of unsupported #SENSE images.

Export of Geosoft Version 2.00 ASCII files is supported. These files are exported with a type of "GXF". They can only hold one channel.

See Also

GGF, PLT


GTOPO30

GTOPO30 is a global digital elevation model (DEM) with a horizontal grid spacing of 30 arc seconds (approximately 1 kilometer). GTOPO30 was derived from several raster and vector sources of topographic information.

GTOPO30, completed in late 1996, was developed over a three year period through a collaborative effort led by staff at the U.S. Geological Survey's EROS Data Center (EDC).

The GTOPO30 format consists of three files .DEM, .HDR and .PRJ. The .DEM file contains the image, the HDR information about the image and the PRJ. To open the dataset, specify the HDR file.

Creation of GTOPO30 format imagery is not supported.


Hierarchical Data Format (HDF-EOS)

The HDF-EOS format is a specialized organization of HDF (Hierarchical Data Format) files produced by some NASA EOSDIS programs. In particular, it is being used by the ASTER program. GeoGateway currently offers support for HDF-EOS "Swath" products and HDF-EOS "Grid" products. It does not support point datasets.

Swath products are simple images that have not necessarily corrected to any map projection grid. Swath products have no georeference information but may have "LONG/LAT" GCP's. Swath products can be identified by the GeoGateway identifier ("hes") that is appended to the filename for internal processing.

Grid products are images that have been corrected to a map projection grid and they will be imported with georeferencing. Because Grid products are already georeferenced, no GCP's are required or produced for Grid products. Grid Swath products can be identified by the GeoGateway identifier ("heg") that is appended to the filename for internal processing. (In the following discussion, although Swaths are discussed, the same discussion can be applied to Grid products. That is, what applies for Swaths can apply just as well for Grids.)

The HDF-EOS translation is implemented using the NASA EOSDIS support libraries and the NCSA (National Center for Supercomputing Applications) support libraries.

HDF-EOS swath files are organized as a series of datasets, each called a swath. Typically each swath is the output of one band of a sensor instrument. However the swaths can have different resolutions, making them difficult to treat as a single dataset in GeoGateway. If there is only one swath in the dataset, GeoGateway does not have to make any decision as to which swath to process and it will just carry on with no further questions asked.

However if there is more than one swath, the swath to process has to be specified for GeoGateway. How this is done depends on the interface:

  • For a graphic program (e.g. focus) a "Select" window with the different swaths in the dataset is presented and the swath to process would be selected and opened.
  • For a non-graphic program (e.g. FIMPORT) the file, format and swath would have to be specified.

For example:

 EASI>fili="GDS_L1A.hdf:hes:VNIR_Band4:(2048 x 2100 x 1)"

Consists of four parts (separated by ":" dividers):

  • The name of the file, "GDS_L1A.hdf"
  • The GeoGateway identifier for HDF-EOS Swath, "hes"
  • The swath to process in the dataset, "VNIR_Band1"
  • The layer dimensions, "(2048 x 2100 x 1)" where the first dimension is pixels per line, the second dimension is lines per layer, and the third dimensions are the layers in the swath. The layer dimensions normally are only displayed if there are layers with different dimensions within the same swath.

Because of this complicated naming process, it is better to use MULTIRD rather than FIMPORT to import an HDF-EOS dataset to produce PCIDSK file(s). MULTIRD is an EASI procedure that does the following:

  • runs FIMPORT once to produce a parent file

This file will always be 512 pixels by 512 lines by 0 layers. The only thing of importance is metadata information describing the Children (or Swaths) of the parent.

MULTIRD uses the Children metadata from the parent PCIDSK file to make up the names of the Swaths and the output PCIDSK files. MULTIRD will loop through until it imports all the swaths.

You can import one swath directly with FIMPORT if you follow the naming convention of the ChildDataset REF record of the metadata (omitting the "gdb:" prefix).

If you get the following message:

 ERROR:   The file `GDS_L1A.hdf' is an HDF file, but it can't
 be read as an RI8, or SDS dataset.  Only these HDF
 subformats are supported by GeoGateway.
 E019 ... Invalid header type

This means that the file could not be opened with either the HDF-EOS Swath or Grid formats or any other HDF methods. This message originates from the HDF GeoGateway, which normally is only used when all other methods failed.

See Also


HIDISK (HI-VIEW Image Format)

The HIDISK image format used by the Horler Information Inc. HI-VIEW software (Version 111) is supported by the GeoGateway library for reading. Writing in this format has not been implemented.

Only 8-bit unsigned, 16-bit signed, 16-bit unsigned, and 32-bit real data will be read (32-bit signed integer data is not supported).


Hyperspectral Image Data format (.VQ)

The format for compressed hyperspectral image data Data format version 2:

Datatype                   Description
Unsigned short             Version
Unsigned short             Number of bits required to represent a
                           codebook vector index (#bits)
Unsigned short             Number of rows (#rows)
Unsigned short             Number of columns (#cloumns)
Unsigned short             Number of spectral bands (#bands)
Unsigned short             Maximum intensity to be plotted
Byte[64]                   String giving the unit for intensities
Float[#bands]              Wavelengths in microns
Unsigned short[#bands][2^#bits]            Codebofok vectors
Usigned byte-packed[#rows][#columns]       Byte-packed Index map

Byte-packed compressed data is organized as follows:

  1. The bits that represent each element are in general spread across two or more bytes in memory (exception: when the data word size equals 8 bits)
  2. The byte that contains the element's higher-order bits precedes in memory the bytes that contain the element's lower-order bits
  3. Data is packed contiguously. Higher-order bits are filled first, and lower-order bits are made available for storage of the next element.
  4. The word size of each element is between 8 and 16 inclusively


Image Display Handler

On Unix systems it is possible to access the display (ImageWorks or the Handler) as if it were a file, via the GeoGateway library. Possible filenames that would refer to the display are "VD00", "VD0:", "VD1:", "VD2:", or "VD3:".

It is possible to access the image planes of the display as channels, graphic planes as bitmaps, and vector layers as vector segments. The LUTs and PCTs are also accessible. The overall georeferencing (in the manner of Set Map Area) is also accessible.

Note: The old Handler does not support georeferencing or vector layers.


Idrisi Rasters

The GeoGateway library supports Idrisi 2.x raster images (.img) for import and live linking. An Idrisi raster image consists of at least two files, with the header information stored in a file with the extension .doc. Normally the image data is stored in a similarly named file as that with the .img extension. Note that Idrisi 24-bit (RGB) rasters are not currently supported.

All Idrisi raster data types are supported. That is, 8-bit (byte), 16-bit (integer) and 32-bit real (real) images are supported. All Idrisi file types, such as "ascii", "binary" and "packed binary" are also supported for reading. Only "binary" is supported for writing. And, of course, the same limitations that exist in Idrisi for the combinations of data and file type exist in PCI; for example, Idrisi does not support packed binary real.

PCI reads and applies the georeferencing information contained in the .doc file. A "lat/long" reference system will result in a Latitude/Longitude projection using the WGS 1984 datum. A "plane" reference system will result in a meter projection. The user can apply the correct and full projection definition if that information is available to them within the PCI environment.

The Idrisi raster's minimum and maximum X and Y coordinates are used to define the extents of the image and its resolution calculated based on those inputs. Its minimum and maximum values are also used to assign SCALING_MIN and SCALING_MAX values for the raster; and, if provided, flag definition values will be used for NO_DATA_VALUEs.

If the raster has an associated palette file (.pal), its red/green/blue settings will be used to construct a pseudo-colour table for the raster in PCI. These palette files should have the same basename as the .img and .doc and be located in the same directory. Idrisi's binary palette files, .smp, are not supported as the format definition for these files is not published.

If an image's reference system identifies the basename of an Idrisi Reference System Parameter File (.ref), PCI will use the specifications in that file to create the proper projection definition. These files are assumed to exist in the "georef" directory below the Idrisi system directory or in the same directory as the Idrisi raster files. To indicate, to PCI, the location of Idrisi system directory, the user must set a system environment variable, "IDRISI_SYSDIR", and point to the proper location. For example, on Windows 95/98, the user would enter the following in their autoexec.bat:

set IDRISI_SYSDIR=c:\idrisi

If c:\idrisi was the full path to their Idrisi software. PCI will then look under c:\idrisi\georef directory for the file indicated by the basename in the ref. system of the documentation file.

From the .ref, PCI supports "Mercator", "Transverse Mercator" and "Lambert Conic Conformal" projections. "none" is interpreted as Latitude/Longitude. All other projections will be treated as generic meters. If, after evaluating the entire reference system files contents, a "Transverse Mercator" entry is found to define a typical Universal Transverse Mercator (UTM) projection, PCI will switch the projection to UTM and indicate the correct zone in its software.

The datums supported are "NAD27" and "NAD83". NAD27 datums will use the Clarke 1866 (E000) ellipsoid and NAD83, the North American 1983 (D122) in PCI. If another datum is specified, the major and minor s-axis entries are used to indicate the ellipsoid instead and a default "E999" shown in PCI.

It should be noted that on export to Idrisi format, PCI will not create a reference system file and the .doc will indicate "plane" only unless the raster is in a Latitude/Longitude projection. The user can, of course, use the information conveyed in the PCI projection panels to create a useable .ref for Idrisi and utilize it by changing the entry in the .doc.

IDRISI32 Version

1. Idrisi32 version has a ".rst" extension for Raster images, a ".rdc"
   for documentation file.
2. a new line called "file format" has been added for version checking.

   IDRISI32 requires that all raster files be in "IDRISI Raster A.1" format.
3. "Display Min" and "Display Max" entries have been added. Autoscaling now
   uses these values rather than the actual minimum and maximum as the scaling
   points. By default, most analytical modules set these to be identical to
   the min and max values.
4. RGB8 datatype be added.The RGB8 is simply a byte binary file. However,
   it is understood by IDRISI32 that this is specifically an 8-bit RGB
   composite. It therefore automatically knows it should use the
   COMPOSIT.SMP palette with this file
5. RGB24 datatype be added.The RGB24 is essentially equivalent to the data
   portion of a Windows BMP. It contains 3 bytes per pixel in blue, green,
   red order. IDRISI32 automatically understands that it should display such
   files as 24-bit images.


Idrisi Vectors

IDRISI vector files are supported by the GeoGateway library for import and export. The file format contains vector and header information. Typically, datasets include two files with a common basename and the extensions .vec and .dvc. we can open with either of them.

Vector files contain the identifiers and coordinates that define vector features. Vector files may contain only one feature type (point, line, polygon or text) per file.Vector files must be accompanied by Vector Documentation files for use.Vector files may be stored as ASCII or binary files. Now we only support ASCII format.

IDRISI supports a single uniform vector file structure for points, lines and polygons. This is a feature encoded structure since each feature is described in its entirety before the next is described. For all feature types (point, line, polygon), the file consists of a sequence of numbers indicating: 1) a feature identifier, 2) the number of points that define that feature, and 3) the X and Y coordinates for each point.

Any number of features may be contained in the same file, but each file must contain only one feature type (point, line or polygon). Every file ends with a pair of zeros. The format of a text file is exactly the same as that of a point file. The vector file stores the location of the text, while the actual text labels are stored in the Attribute Values file.

Vector Documentation files store important information about the Vector file(the metadata, or header information). The following parameters are recorded in Vector Documentation files:

title:       A descriptive name of the file.
id type:     The data type of the feature identifiers in the vector file.
             The coordinates themselves are always stored as real numbers.
             The identifier type may be integer or real.
file type:   The way the file is stored in the computer. This may be ASCII
             or binary. We only support ASCII type file.
object type: One of the point, line, polygon or text.
ref. system: The name of the geographic referencing system used with the
             file. This may be Plane, Lat/Long, or a specific referencing
             system defined by a Reference System Parameter file.
ref. units:  The unit of measure used in the specified reference system.
unit dist.:  The scaling factor between the given coordinates and actual
             measurements on the ground. This will almost always be 1.
             This entry answers the question, "One unit in the
             reference system is equal to how many units on the ground?"
min X:       The minimum X coordinate (left edge) of the bounding rectangle.
max X:       The maximum X coordinate (right edge) of the bounding rectangle.
min Y:       The minimum Y coordinate (bottom edge) of the bounding rectangle.
max Y:       The maximum Y coordinate (top edge) of the bounding rectangle.
pos'n error: An indication of the accuracy of the locations of features in
             the file. The RMS value from a digitizing or resampling operation
             may be recorded here.The value may also be specified as "unknown".
resolution:  The typical distance between points in a feature in the Vector file.

See Idrisi Rasters for information on georeferencing.


ILWIS Raster

The GeoGateway library supports ILWIS 2.x Raster images (.mpr) for import and live linking. An ILWIS raster image consists of several different files, with the header information stored in a file with the extension .mpr. Normally the image data is stored in a similarly named file with the extension .mp#. Note that ILWIS 1.x raster images are not supported.

Only 8bit (byte), 16bit (int) and 32bit (long) images are supported. 32bit (Long) is read as 32 real in GDB. One bit, and real images are not supported at this time.

If the raster has "GeoRefCorners" georeferencing, the corner coordinates for the raster are read from the .grf file, and represented as the georeferencing of the image.

If the raster has a class representation, the translator will read the associated PCT information from the .rp# file.

If there is an associated .csy (coordinate system) file, the translator will search for, and read the file to get the projection definition. At this time, the only projections recognized by the translator are UTM, Albers EqualArea Conic, Azimuthal Equidistant, Equidistant Conic, Lambert Azimuthal EqualArea, Lambert Conformal Conic, Miller Cylindrical, Mercator, Oblique Mercator PolyConic, Robinson, Stereographic, Sinusoidal and Transverse Mercator. All other projections will be treated as generic metres.

There is no support for exporting ILWIS data, or writing data other than the image itself to an existing ILWIS dataset.


ILWIS Vectors

The GeoGateway library supports ILWIS table and vector files for import. An ILWIS table and vector dataset consists of several different files.

Version 2.x

ILWIS tables consist of a .tbt file with associated .tb#, .dom and .dm# files.

ILWIS pointmap (points) dataset consist of a .mpp file with associated .pn#, .tbt, .tb#, .dom, and .dm# files.

ILWIS segmentmap (line) dataset consist of a .mps file with associated .cd#, .sg#, .sc#, .dom and .dm# files with a possiblity of having an associated table.

ILWIS polygonmap (area) dataset consist of a .mpa file with associated .pl#, .pc#, .tp# and segmentmap files.

Geogateway does not currently support any ILWIS symbolic representations.

If there is an associated .csy (coordinate system) file, the translator will search for, and read the file to get the projection definition. At this time, the only projections recognized by the translator are UTM, Albers EqualArea Conic, Azimuthal Equidistant, Equidistant Conic, Lambert Azimuthal EqualArea, Lambert Conformal Conic, Miller Cylindrical, Mercator, Oblique Mercator PolyConic, Robinson, Stereographic, Sinusoidal and Transverse Mercator. All other projections will be treated as generic metres.

Version 3.x

Pointmaps

In ILWIS 2.0 a pointmap was a table with three columns, X (double), Y(double) and Value. In 3.0 the map is still a table but there are only two column: a column of the type coordinate and a column of the value type (same as 2.0). The coordinate column is stored as pairs of consecutive doubles (X,Y). The actual binary file is the same as the old format but for ILWIS its organization is different. One note, the extension of the file has been changed to .pt#.

Segmentmaps

Here the changes are quite extensive. Gone are CD# and SG# file that accompanied the mps file. There is only one data file with the mps is file the mps# file. The file has the same structure as a table file in ILWIS.

The mps# file is a table with 5 columns. The first column gives the Minimum value of the coordinates (X,Y) of the bounding box, both doubles. The second column has the maximum coordinates(X,Y) of the bounding box., both doubles. The third column gives the actual coordinates of all the points of the segment (including begin and end). This field has a variable size. The first number is the number of bytes that is used for the field (long). Then all the coordinate in pairs of doubles (X,Y) follow. The number of coords times 16 gives the number of bytes used. The fourth column states if the segment is deleted or not. It is stored a long with a 1 indicating it has not been deleted and 0 indicating it has been deleted. The last column contains the value of the segment. This may be either a raw value or a real value (double).

Polygonmaps

Polygon map data files have been redesigned along the same lines as segment files. In this case there are two data files. The mpap# and the mpat#. The first file is a table that contains data of the polygon. The second contains the data of the topology.

The structure of the mpap# is a table with 7 columns. The first two columns are the same as for segment maps, the bounding box. The third column is the area of the polygon (double), the fourth column is the length of the boundary (double). The fifth column gives an index in the topology file (see below) indicating where the topology for this polygon starts in the topology file. This index is a long. The sixth column gives the value of the polygon (raw value) and the last column states if the column is deleted.

The structure of the table can be seen in the mpa file of a polygon map. There is a table section there with all of its corresponding columns.

The second data file contains the topology information of the map. It is basically the same as the mps# file with some extensions and no value column. The file is again a table with the first four columns the same as the mps#. After that four columns are added: Which polygon is to the left, which is to the right and forward and backward link of the polygon segment. The links are indexes in the table just as the left and right polygon are in the polgyon table (first file).

The columns of the topology table can also be found in the mpa file. The table sections have the prefix 'top:'.


Intergraph Raster Files

The GeoGateway library supports some variants of the Intergraph Raster format. No auxiliary or georeferencing information is supported for Intergraph Raster format files. Intergraph raster files may have a variety of extensions including .rgb, .cot, and .cfl.

The supported sub-formats are: grey scale continuous tone (type 2), compressed RGB (type 27), and uncompressed RGB (type 28). Type 28 has not been tested.

Continuous Tone files cannot be created with Works programs, but the imagery on an existing file can be updated, if it is not of type 27. The PACE LINK program can be used to access Intergraph Raster data in type 2 and type 28 files.


ISDAS Spectra Library

Each spectrum in an ISDAS Spectra library corresponds to one record in the GDB layer. Each wavelength is shown as a separate field. The field name is the letter 'm' followed by the wavelength value. Decimal points appear as underscores in the name. There may also be a quality field for the same wavelength. Its field name has an initial letter 'q'. Other metadata for the spectrum of that target appears at the end of the record.

ISDAS spectra are ASCII tables read using the GAV format.

See Also


Joint Photographic Experts Group (JPEG) JFIF Files

The GeoGateway library supports single scan JPEG files that contain 8-bit grey scale or 24-bit colour images. GeoGateway will read both YCC and the less common RGB colour space JPEG files, but will always write the YCC variant.

The GeoGateway JPEG support is based on the Independent JPEG Group's (IJG) version 4 code. A suite of public domain Unix tools for dealing with JPEG files is available by anonymous ftp from ftp.uu.net in the directory graphics/jpeg.

Projection information is read from an ESRI World File with extension .jgw or from a MapInfo TAB file with extension .tab if either of these files is present. See TIFF for the specifics on how georeferencing is assigned using a World File. If no such file is present, a PIXEL projection will be assigned.

Export of JPEG JFIF files is supported. These files are exported with a type of "JPG".

JPEG files do not normally contain any auxiliary information such as georeferencing, LUTs, or PCTs; however, an .aux file is written upon export, and this will be honoured when reading PCI generated JPEG files. Georeferencing can be generated when the file is generated by specifying the WORLD option. This generates an ESRI World File in a .jgw file.

Only one (greyscale) and three (RGB colour) bands may be exported to a jpeg file. There is an option to specify a numerical percent 'quality' of the resulting JPEG file. The default quality is 75. More quality implies a bigger image. The useful range of this parameter is approximately 15-90. The parameter is specified simply by entering the number.

Note that JPEG is a lossy compression, and under no circumstances will the image be preserved exactly, even if the quality is 100.


JPEG 2000

Most common forms of JPEG2000 and GeoJP2 (tm) files can be read and written by the GDB library. JPEG2000 is a wavelet based successor format to the popular JPEG format that includes several features that make it attractive for geospatial applications. These include the support for fast overview extraction, 8bit and 16bit data types, the ability to extract subregions and support for embedding extra metadata within the container file.

The GeoJP2(tm) format is an extension of the JPEG2000 format where georerencing and coordinate system information is included within the JPEG2000 JP2 file. GeoJP2(tm) is a trademark of Mapping Science, Inc. The GeoJP2(tm) format includes support for all georeferencing modes and coordinates systems that can be described by GeoTIFF. A GeoJP2(tm) file should still be readable by JPEG2000 JP2 readers that are not geospatially aware (i.e., almost any other application that can use JPEG2000). Information about GeoJP2(tm) can be found on the Mapping Science web site:

http://www.mappingscience.com

The JP2 format is the most common form of JPEG2000 data; however, some other forms exist. One form is the "JPC" format, a raw JPEG2000 data stream. This format is supported for read and write, but may not have associated georeferencing or coordinate system data. It is required to have the extension .jpc.

For reading GDB supports greyscale, RGB, color encoded as YCbCr (automatically converted to RGB while reading), and multispectral. Eight bit unsigned, 16bit signed and 16bit unsigned data types are supported.

Export to JPC and JP2 format is support with the format type "JP2". To generate a JPC instead of a JP2 format file use the extension .jpc for the file. All files generated with extensions other than JPC will be JP2 files. On export any number of 8U, 16U or 16S bands may be exported. It is currently not possible to generate YCbCr encoded files; however, RGB color files can still be generated in the RGB color space - by exporting three or more bands. JPEG2000 export does not support LUT, GCPs, or vector data. Only imagery and PCTs are supported.

For export, the QualityPercent option may be set to control the degree of compression in the generated file. The argument is a number from 1 to 100 indicating the size the compressed file should be relative to the uncompressed size of the image being written. The default is 20, indicating the output file should be approximately 20% the size it would be if uncompressed. The QualityPercent keyword may be omitted. Depending on the data, a QualityPercent value of 5 or less may still produce a useful output.

If a value of 100 is selected for QualityPercent or the Lossless option is used, then a lossless compression mechanism is used. The resulting image can be read back without any alteration to the image values, though typically the degree of compression acheived will be 30% to 50%.

The ROI option with coordinate values define the origin and the size of a region of interest where compression is less than the overall image. The compression within the ROI is given by the Rweight option which is the relative compression. The default value is 7.


JPEG 2000 File formats and Extensions

JP2 is a particular format wrapped around a JPEG2000 data stream (sort of like JPEG JFIF is a wrapper around the raw JPEG data stream). The .jpc, .jpx and .j2k are common extensions to use for raw jpeg2000 data stream files. Georeferencing information can only be written into JP2 formatted files, not raw compressed image streams (like .jpc).

JPC is the raw jpeg2000 data stream. This does not contain any georeferenced information.

JPX and J2K are presently not supported within PCI gdb formats.


Compression Details

The quality value given when compression with JPEG2000 is a target size relative to the size of the source image. So for example 80 is a request that the resulting image be 80% the size of the source image.

However, there is a certain amount of compression that can be achieved almost losslessly. For an input image with relatively low information content the compressor will not make the output file larger than it needs to. In other words if the compressor can create a virtually lossless image smaller than the size requested, it will.

For example, imagine an image that can be compressed to 25% of its original size with virtual no loss. If a request is made to compress the image by 50% then the compressor will still produce a file that is 25% the original size.


Credits and Copyrights

GeoJP2(tm) is a trademark of Mapping Science, Inc.

JPEG2000 support is based on the Kakadu software libraries.


Examples

The quality value for JPEG2000 files are set in the 'Options' editable field next to the output format.

1 - 99 will set the compression.

100 - will set a lossless compression


Land-Line NTF File (.NTF)

Land-Line data is an enhanced vector data set, where features are represented as points and lines that are digitised and specifically coded to show differing features. It is not a structured data set and, as such, does not contain defined polygons.

Land-Line can be supplied in two different file formats. These are:

  1. National Transfer Format (NTF)
  2. Drawing Exchange File format (DXF)

NTF file are supported by the GeoGateway library for import and view. Three vector segments are used to display NTF file's three data set:

  1. point
  2. line
  3. text
Each contains different attributes with different feature.

Structure of features

The structure of each different feature is as follows:

  1. Points - these consist of:
    • a Point Record [POINTREC] 15
    • a Geometry Record [GEOMETRY1] 21
    • and can have an associated Attribute Record [ATTREC] 14, which contains a measurement for variable sized symbols
  2. Lines - these consist of:
    • a Line Record [LINEREC] 23
    • and a Geometry Record [GEOMETRY1] 21
    • and maybe one or more Continuation Records[CONTREC] 00 to extend the Geometry Record
  3. Text - this consists of:
    • a Name Record [NAMEREC] 11
    • a Name Position Record [NAMPOSTN] 12
    • and a Geometry Record [GEOMETRY1] 21

Coordinate referencing system

Abbreviated National Grid coordinates are supplied and are given in centimetres. The coordinates have a field width of 6, not the NTF default width of 10. Full National Grid coordinates are calculated by using the {XY_MULT}, {X_ORIG} and {Y_ORIG} values in the Section Header Record [SECHREC] 07, and the conversion formulae below:

X = ({XY_MULT} x {X_COORD}) + {X_ORIG}
Y = ({XY_MULT} x {Y_COORD}) + {Y_ORIG}

where {X_ORIG} and {Y_ORIG} are additive constants, always added to {X_COORD} and {Y_COORD} respectively, whilst {XY_MULT} is a multiplication factor applied to coordinates before the addition of {X_ORIG} and {Y_ORIG}. Negative coordinate values may be carried in {X_COORD}, {Y_COORD}. In each case, the minus sign appears as the first character of the field.

See UK National Transfer Format (.NTF) for information on georeferencing.


LAS Image Format

The LAS 5.0 Image file format is supported for read access by the GeoGateway library. The LAS format is used to store various types of geocoded image data. Typically, a LAS image will consist of several related files. The two used by the GeoGateway library are the .ddr and .img files. The .ddr file contains header information and geocoding, while the .img file contains the actual imagery. Either file may be used to refer to the LAS image, but both must exist in the same directory with the same base name.

The GeoGateway library supports reading and updating imagery on LAS files. In some circumstances it is also possible to read georeferencing information. In theory, any of the USGS style projections may work (only UTM has been tested). There is currently no option to export imagery in LAS format.


Laser-Scan (LSC)

Five of the seven types of Laser-Scan image files are supported by the GeoGateway library. Functions exist to read, update, and create Laser-Scan files. Image update of compressed files is not possible.

There is no support for georeferencing, nor any auxiliary data other than pseudocolour tables (PCTs) with Laser-Scan files.

The supported Laser-Scan file types are:

  • 2: Greyscale (uncompressed, LINKable), 1 channel
  • 3: PseudoColoured Image (compressed), 1 channel + PCT
  • 4: RGB (24-bit uncompressed, LINKable), 3 channels
  • 5: Bitmap (uncompressed), 1 Bitmap
  • 7: PseudoColoured Image (uncompressed, LINKable), 1 channel + PCT

The RLE and PackBits compressed bitmap file types (1 and 6) are not supported at this time.

The type 3 compressed pseudocoloured image files use a simple run length encoding scheme. The image channel may not be updated after the initial creation. The pseudocolour table (PCT) may be stored in a related .PAL file, in which case it is available to read. If the .PAL file does not exist the pseudocolours are lost. ".PAL" files are not created on export, and thus a PCT cannot be written out with a new pseudocoloured file.

Export of LaserScan files is supported. These files are exported with a type of "LSC".

Only 8-bit image channels and bitmap images may be exported.

Georeferencing, and channel descriptor information is written to an ".aux" file in the same directory as the laser-scan file.

The option "COMP" is used to specify compressed output. The option "PCT" is used to add a pseudocolour table.


LaserScan IFF Text

The GeoGateway library supports LaserScan's IFF text format for read, and write access. The following attributes will automatically be created for each layer when reading an IFF file:

  • REPCode: Feature Code
  • GroupId: FSN (Feature Serial Number)
  • Angle: RO (Orientation for texts and symbols)
  • Height: AC 3
  • TextString: TX for text features
  • ChildList: Used to group features linked by invisible lines

Layers in the IFF file will appear as separate segments when a file is read in. Creation of new segments (IFF layers) is supported as well.

Export of LaserScan IFF text files is supported. These files are exported with a type of "IFF". If more than one GeoGateway Vector Layer is exported then they will be stored as separate IFF Layers.


LGSOWG CD-ROM

LGSOWG (CEOS) is a magnetic tape format that can be extended to be used as a CD-ROM distribution format. A GeoGateway library support has been added for the base format.

The directory structure and naming conventions may vary. Examples produced by various agencies are as follows. In each case, you would select the imagery file.

A) Spot Image CD-ROMs typically have a directory structure as follows:

  /cdrom/SCENE01/VOLD_01.DAT
  /cdrom/SCENE01/LEAD_01.DAT
  /cdrom/SCENE01/IMAG_01.DAT   <--- Select this file
  /cdrom/SCENE01/TRAI_01.DAT
  /cdrom/SCENE01/NULL_01.DAT
  ...

B) ESA CD-ROMs may have the following structure. The following example is organized in a BSQ (Band Sequential) format for one scene. Each band of the scene is in a separate file, so you would select and then display the imagery, for as many bands as you want.

  ...
  /cdrom/scene1/lea_01.001
  /cdrom/scene1/dat_01.001      <--- Select this file and load imagery
  /cdrom/scene1/tra_01.001

  /cdrom/scene1/lea_02.001
  /cdrom/scene1/dat_02.001      <--- Select this file and load imagery
  /cdrom/scene1/tra_02.001
  ...

C) RADARSAT CD-ROMs may have the following structure:

  /cdrom/lgsowg/vold_01.dat
  /cdrom/lgsowg/lead_01.dat
  /cdrom/lgsowg/imag_01.dat     <--- Select this file
  /cdrom/lgsowg/trai_01.dat
  /cdrom/lgsowg/null_01.dat

D) CCRS CD-ROMs may have the following structure:

  /cdrom/me0072/me0072.vol
  /cdrom/me0072/me0072.ldr
  /cdrom/me0072/me0072.img      <--- Select this file
  /cdrom/me0072/me0072.trl
  /cdrom/me0072/me0072.nul

Currently, none of the header or trailer files are utilized. Only reading and updating of the image data is supported. It is not possible to create these files, nor is there any auxiliary information.

Note: Writing is only supported if the dataset is copied to disk from the CDROM.

LGSOWG magnetic tapes can be read with the PACE program MIL, while LGSOWG CD-ROMs can be accessed via the PACE program LINK.


Gould LIPS (LIP)

Gould LIPS image file format is supported for import and export by the GeoGateway library. LIPS format is a simple pixel interleaved raster format with a 512 byte header. There are three forms: 8-bit monochromatic, 24-bit colour, and 64-bit complex. Of these, only the first two are supported.

No georeferencing information, or other auxiliary data is read or written, from or to, LIPS files. It is possible to LINK to LIPS files.

Export of Gould LIPS files is supported. These files are exported with a type of "LIP".

Only one band (monochromatic) or three band (colour) eight band files can be created.

No georeferencing, or other auxiliary data can be exported to LIPS format.


MapInfo Data Interchange Format (MIF)

MapInfo layers in the form of .mif/.mid files are supported by the GeoGateway library for both read and write with RST support, with some limitations listed below.

All graphical object types are imported with all their attributes, however, ARCs and ELLIPSEs are emulated with line segments 3 degrees long (up to 120 segments in one complete ellipse). Rounded Rectangles are also treated as simple rectangles. PLINEs and REGIONs are converted to one single GeoGateway Shape with a RingStart attribute specifying the index where the sub-regions start in the array of vertices of the shape.

Projections are remapped to best match while reading and writing. However, it is possible that some specific projections have no equivalent. In such cases the projection will be set to "METRE" on import (with the coordinates converted to metres as well) or to "COORDSYS NonEarth" on export.

In write mode, vertices and all attribute types (except CountedInts) are written out. A RST can also be provided as long as it is in Ground Units, and GeoGateway will export the representation information. When you import a file, the best results will be obtained with RSTs that have been generated by this same translator.

Export of MapInfo files is supported. These files are exported with a type of "MIF".

The translator will give better results if an RST (in Ground Units) with the following attributes is available. Note that these are optional and that the export operation will work but without representation information (colours, line widths, etc) if they are not provided:

  • REPCode (Integer) Index to a REPCode in the provided RST.
  • Angle (Double) Orientation for TEXTs.
  • TextString (String) TEXT value.
  • RingStart (CountedInt) Used by GeoGateway to regenerate REGIONs and PLINEs.


MapInfo Table (.TAB)

The Map Info Tables in the form of TAB format are supported by the GeoGateway library for import,export.These format are exported with a type of ".tab".

All graphical object( feature) include TABFCPoint,TABFCFontPoint, TABFCCustomPoint,TABFCText, TABFCPolyline, TABFCArc,TABFCRectangle, TABFCEllipse, TABFCRegion. they are imported with all their attributes.

The Dataset of map info tab typically consists of at least five files which have same file name and different file sxtension( .dat, .id, .ind, .map, .tab). They are binary file except .tab which is small text file describing the format of the file containing your data,When you open a set of mitab file you have to select .tab file.these files must be kept together in same directory in order to be accessed.

MITAB library is an Open Source C++ library to read and write MapInfo .TAB (binary) and .MIF/MID files. It is based on the OGR library which is an implementation of the Open GIS Consortium Simple Feature specification. For more info see:

http://pages.infinit.net/danmo/e00/index-mitab.html

See MapInfo Data Interchange Format(MIF) for information on georeferencing.


Advanced Information About Read Access

While reading, a Representation Table (RST) is built based on the drawing information that is available (line width, colour, etc.). Each object read is given a "REPCode" attribute that points to an entry in this RST. TEXT objects also have a "TextString" and "Angle" attribute in the GeoGateway shape containing the character string and its orientation.

On Import, if there are columns with the names "REPCode", "Angle", "TextString", or "RingStart" in the MAPInfo table structure, then these attributes will not be imported, instead they will be replaced by special GeoGateway attributes with the following contents:

  REPCode       (Integer)      Index to a REPCode in the generated RST.
  Angle         (Double)       Orientation for TEXTs.
  TextString    (String)       TEXT value.
  RingStart     (CountedInt)   Used by GeoGateway to regenerate polygons and
                               polylines.

These special attributes are fetched by GeoGateway in the following order:

  1. If the application provides setting for these attributes (through the layer's iXXXField members) then these will be used.
  2. If an attribute with the right name and type exists, then it will be used.
  3. Finally, if the 2 cases above failed, then some default values will be used instead of attribute values.

GeoGateway needs the layer extents at the beginning of the export operation to give the best results when exporting with a RST. If the application does not provide that information to GeoGateway, then default values will be used for line widths (always 1 pixel) and symbol sizes (always 10 points). If you have such columns in your dataset and want to keep them untouched, then you should change their name with MAPInfo's Table Structure tool.

Note: The test on the names is not case sensitive.

The column types that do not have a direct equivalent in GeoGateway are remapped without any data loss. DATEs are imported as Strings, LOGICALs are imported as Integers with 0=False/No and 1=True/Yes, and DECIMALs are imported as Floats.


Advanced Information About Write Access

On Export, the translator will give better results if a RST (in Ground Units) with the following attributes are available. Note that these are only optional, and that the export operation will work but without representation information (colours, line widths, etc.) if they are not provided:

  REPCode       (Integer)      Index to a REPCode in the provided RST.
  Angle         (Double)       Orientation for TEXTs.
  TextString    (String)       TEXT value.
  RingStart     (CountedInt)   Used by GeoGateway to regenerate REGIONs and PLINEs.

These special attributes are fetched by GeoGateway in the following order:

  1. If the application provides setting for these attributes (through the layer's iXXXField members) then these will be used.
  2. If an attribute with the right name and type exists, then it will be used.
  3. Finally, if the 2 cases above failed, then some default values will be used instead of attribute values.

GeoGateway needs the layer extents at the beginning of the export operation to give the best results when exporting with a RST. If the application does not provide that information to GeoGateway, then default values will be used for line widths (always 1 pixel) and symbol sizes (always 10 points).


Limitations Due To RST Units

Since GeoGateway deals with a RST in which the units are Metres on the Ground, while MapInfo uses line widths in pixels and symbol sizes in points, GeoGateway must perform an approximation while converting between the MapInfo file and the RST. Fortunately, text sizes are already attached to Ground units in MapInfo, therefore in this case GeoGateway does an exact conversion.

To map pixel and points sizes to ground metres, GeoGateway makes the assumption that the dataset is intended to be viewed on a 1280 pixel wide screen, where each pixel is 0.28mm wide. With these values and the file's extents, GeoGateway can convert MapInfo line widths and symbol sizes to/from the RST.

Another approximation is required if the dataset's projection is LAT/LONG. In this case, GeoGateway must remap the representation information (for text height) from degrees to metres in the RST. The heights in degrees are converted as though we were dealing with a perfect sphere with a radius of 6370997m. Thus, a text height of 1 degree is approximated to 111195 metres in the RST.

Note: These limitations only apply to the RST. Datasets in LAT/LONG are imported and exported directly, without any conversion of their coordinates.


MERIS (Medium Resolution Imaging Spectrometer)

GDB supports only one of the Medium Resolution Imaging Spectrometer (MERIS) product which is the MER_RR__BP product.

To get more information on the Envisat MERIS products, please consult the following web site:

http://envisat.esa.int/dataproducts/meris/

See Also

ASAR


MicroStation Design Files (DGN)

MicroStation DGN files are supported by the GeoGateway library for read access and limited write access. Both Raster and Vector data may be read from DGN files.

Three formats of Raster Imagery are supported: Compressed Binary, Binary, and Byte. The georeferencing system for raster imagery is PIXEL.

The supported vector entities are LINEs (3), LINESTRINGs (4), SHAPEs (6), ELLIPSE (15 - 2D only), ARC (16 - 2D only), TEXT (17) and TEXT (37). CURVEs (11) are defined by interpolating through all points. SPLINE POLEs (21) are supported as similarly splined polylines.

For CELLs and COMPLEX elements, the individual elements comprising the complex element are read as parts of one shape. Cell components become Rings in GDB.

The georeferencing system for the vectors is PIXEL. Color, line style, line width and text size information is used when creating the direct RST for the layer. White is mapped to black since PCI software uses a white background.

Files with a master unit of DG and sub-units of MN are latitude/longitude files in GDB. Otherwise the georeferencing is just meters. Attribute linkage information becomes additional fields in the GDB layer.

Unsupported entities are ignored during the read operation.

There is limited write access for DGN. Only TEXT, LINE and LINESTRING elements are created. This means that if a DGN file is imported, edited, and exported, the entity types are not preserved.

There are four options that can be used when creating a new DGN file. They are:

/XOff=xxxx               an offset in UORS to add to the x value
/YOff=yyyy               an offset in UORS to add to the y value
/SubPerMaster=sss        number of sub-units per master units ie meters per
                         kilometer
/UORPerSub=uuu           number of uors per sub-unit ie  millimeters per meter

The XOff and YOff set the Global Origin in the DGN file. The values must be set in UORs. It is suggested that the user select the Global Origin within the the extents of the layer to ensure that the UOR coordinate values do not overflow.

The number of significant digits in the coordinates in the design file is determined by the UORs per Master Unit. For example: For a UTM coordinate with 6 decimal places, use /SubPerMaster=1000 and /UORPerSub=1000. 12 digits need to be used in the XOff and 13 digits in the YOff. The XOff and YOff are typically negative.

The names of the Working Units cannot be set in the Translate panel. By default the units are Km and M. The important aspect is to correctly set the SubPerMaster and the UORPerSub values. In MicroStation the unit abbreviation can be changed without affecting the Working Units or coordinate values.


MrSID Compressed Rasters v.1.2 (SID)

The GeoGateway library supports LizardTech's Multiresolution Seamless Image Database format (MrSID) for live linking and import. LizardTech's Decompression Library API (v.1.0.3) was used to introduce this functionality in PCI products and it is, therefore, only available on 32-bit Windows operating systems.

A compressed image is one that has been reduced in size, but still maintains an almost perfect version of the original. There are various compression techniques, but it is wavelet compression that is used by LizardTech's software. Lossless compression, as the name implies, results in a compressed image that can be perfectly reconstructed to be identical to the original image. Its main advantage is this ability of perfect reconstruction, but its main disadvantage is that it is typically limited to a compression of 2:1. Wavelet compression, however, is a lossy compression, which means that some information is thrown away in order to achieve the much higher compression rates than is possible with lossless compression. Here, the main advantage is the higher compression ratios, but the disadvantage is that the compressed image can not perfectly reconstructed to be identical to the original.

MrSID files may be a stand-alone file ".SID" or have an associated ".SDW" file. A SDW file is similiar to a TIFF World file. See TIFF for the specifics on how georeferencing is assigned using such a file. if no SDW file is present, the image will be assigned a PIXEL projection.

An example of an SDW file and its geo-referencing is as follows:

0.20000000000000           x-scale; dimension of a pixel in map units
                           in x-direction
0.00000000000000           rotation term (not used by PCI)
0.00000000000000           rotation term (not used by PCI)
0.20000000000000           negative of y-scale; dimension of a pixel
                           in map units in y-direction
3615780.10000000000000     x map unit co-ordinate of centre of
                           upper-left pixel
2127219.90200000000000     y map unit co-ordinate of centre of
                           upper-left pixel

The y-scale (E) is negative because the origins of an image and a geographic coordinate system are different. The origin of an image is located in the upper-left corner, whereas the origin of the map coordinate system is located in the lower-left corner. Row values in the image increase from the origin downward, while y-coordinate values in the map increase from the origin upward.

Projection information (that is, the map unit co-ordinate system being used is not indicated) is not stored in SID or SDW files generated by MrSID Encoder version 1.2 or less. This has changed with MrSID Encoder v.1.3, but the Decompression Library API v.2.0 enabling access to this information was released too late to incorporate their support for this release (Winter/00). This means that PCI does not currently support the Metadata generated by MrSID Encoder 1.3 or better.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

MS Access

See DAO

GeoGateway (GDB) Locate in TOC | Prev | Next


NDF (NLAPS Data Format)

The National Landsat Archive Production System Data Format (NLAPS Data Format) is the distribution format used by the USGS (Eros Data Center) for Landsat data. It apparently supersedes use of Eosat Fast Format from the Eros Data Center. NDF format is a CDROM raster image format supported for read, but not for creation.

NDF datasets consist of a number of files, as shown below. In order to read an NDF dataset it is necessary to select the header file (the one with the extension `.hd'). Once this is selected, each of the band files (.i1, .i2, etc.) will be opened. If the naming conventions are different than those shown here, it may not be possible to read the dataset.

-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:33 01196082.dat
-r-xr-xr-x  1 11431  24       889 Sep 18 15:33 224242.sum
-rwxrwxr-x  1 11431  24       588 Sep 19 08:27 YMTRANS.TBL
-r-xr-xr-x  1 11431  24      2565 Sep 18 15:33 lt501704.hd <-- Header File
-r-xr-xr-x  1 11431  24    100836 Sep 18 15:33 lt501704.hi
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:36 lt501704.i1
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:38 lt501704.i2
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:40 lt501704.i3
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:43 lt501704.i4
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:45 lt501704.i5
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:48 lt501704.i6
-r-xr-xr-x  1 11431  24  44073342 Sep 18 15:50 lt501704.i7
-r-xr-xr-x  1 11431  24     20836 Sep 18 15:50 lt501704.wo

NDF data can potentially have many variations, however the translator has only been tested with a few typical output products. Some precision geocoded products may include a DEM; these cannot be read.

All the information from the header file will be imported as a text segment in order that the information is preserved with the dataset for later review. A ground control point segment will be generated with five points representing the four corner points and the central reference point of the image. The datasets can be easily geocoded using GCPWorks and these included control points. However, even geocoded products are produced with some rotation from north, therefore it is not possible to treat the original dataset as geocoded.

The CDNLAPS PACE task can be used to import NLAPS data with the ephemeris data required for satellite ortho correction preserved. The MNLAPS PACE task can be used to read NLAPS tapes. CDNLAPS and MNLAPS are part of the satellite ortho correction package.


NITF (NIT)

A subset of the NITF (National Imagery Transmission Format), used by the the U.S. Government, is supported by the GeoGateway library for reading and writing. The imagery may be Version 1.1, 2.0 or 2.1.

Uncompressed 8-bit unsigned, 16bit signed, and 32bit real data can be processed. Version 1.1 would be one channel data. Version 2.0 may be up to 9 channels. Pseudocolour tables are supported.

RPF format NITF files use Vector Quantization compression and tiling. They may have a LUT which is imported with the image channel. In these cases, the value 216 will be used as a no-data value (as it is found in the file). The RPF format use of NITF is highly specific, and there is no reason to believe that non-RPF files that are tiled or compressed will be properly supported.

Where the Image Coordinate System is G (Geodetic) or C (Geocentric), NITF files will have 'LONG/LAT' Georeferencing when read. NITF files with Military Grid Reference System (MGRS) Georeferencing will have 'UTM' Georeferencing when read. All other Georeferencing is treated as 'PIXEL'.

Export of NITF files is supported. These files are exported with a type of "NIT".

If the NITF file being created does not have a "LONG/LAT" or "UTM" georeferencing, the output NITF file will "PIXEL".

  • NITF Version 1.1 can accommodate only one channel.
  • NITF Version 2.0 can accommodate up to 9 channels.
  • NITF Version 2.1 can accommodate more than 9 channels.

The following options control the version number:

  • "1.1" NITF Version 1.1.
  • "2.0" NITF Version 2.0.
  • "2.1" NITF version 2.1.

Newly created NITF files can be created with a JPEG compression. An option of "Compression JPEG#" will create a JPEG compressed file with a compression ratio given by the #. The ratio has a value from 0 to 100 (no compression).

The default is NITF Version 2.0.

 option =            | NITF Version 2.0;
 option = "1.1"      | NITF Version 1.1;
 option = "2.1"      | NITF Version 2.1;


NTX (Caris Interchange Format)

Caris Vector Interchange (NTX) files are supported by the GeoGateway library for read access only. The supported vector entities are CurvedLines (1), Point-to-Point Lines (3), DashedLines(4), TextWithPosition (6), Names (7), Symbols (8), and SpotHeights (11).

Unsupported entities are ignored during the read operation.

The supported Ellipsoids are:

  • (CL66) Clarke 1866
  • (INTL) International
  • (AUST) Australian N.S.

The supported Projections are:

  • (LC) Lambert Conformal
  • (ME) Mercator
  • (PO) Polyconic
  • (PS) Polar Stereographic
  • (TM) Transverse Mercator
  • (UM) Universal trans. Merc.
  • (GN) Gnomonic
  • (SC) Simple Conic

The following attributes will automatically be created for each layer, when reading an NTX file:

  • Repcode: UserNumber
  • GroupId: GroupId (Number of the entity)
  • Angle: Angle
  • TextString: TextString


ODBC (Open Database Connectivity)

ODBC technology is a standard programming language interface used to connect to a variety of data sources like Microsoft Access, Oracle, etc. This is usually accessed through Control Panel, where data source names can be assigned to use specific ODBC drivers.

Data Source Name (DSN)

An ODBC term for the collection of information used to connect your application to a particular data source (database application). The ODBC Driver Manager uses this information to create a connection to the database. A DSN can be stored in a file (a file DSN) or in the Windows' Registry (a machine DSN).

Choose a DSN from Geomatica

To access a DSN through Geomatica, first select from the File menu the Open option. Then, from the File Selector dialog box press the Choose Other button. Finally, from the Driver list box of the Choose Other dialog box select the ODBC option. Following this selection, you must choose a DSN from the Select Data Source dialog box to connect to a database within a database. That's it.

Difference between File and Machine DSNs

A DSN stores information about how to connect to a particular database. The ODBC driver manager uses the information in the DSN to establish and manage the connection.

There are two types of DSNs. Both types store information needed to make a connection to a database server, but they store it in different locations. The two types are:

  • File DSN Connection
  • Machine DSN Connection

File DSN Connection

File DSN Connection information is stored in a file that can be read by any a feature which makes the project more easily portable between computers. As a general rule, you should always use file DSNs.

Machine DSN Connection

Machine DSN Connection information is stored in the Windows' Registry of the computer on which the data connection is created.

You can choose either a file DSN or a machine DSN from the Select Data Source dialog box, which opens when you choose to create a new data connection. You can also either select an existing data source name or create a new one.

In order to connect to a particular database server, you must have an ODBC driver for that database server. If the ODBC driver you need doesn't appear in the ODBC Data Source Administrator dialog box, you might not have the correct ODBC driver installed on your computer. Check your database's documentation to determine whether there's an ODBC driver available for it.

If you're developing a client-server application, you can use either a file DSN or a machine DSN to add a data connection. When you build the setup program for your application using the setup wizard, you must set up a machine DSN on the user's computer. You do this by modifying the user's registry to contain the information needed to make the connection.

A file DSN stores information about a database connection in a file. The file has the extension .dsn and by default is stored in the $\Program Files\Common Files\ODBC\Data Sources directory.

Create a new file DSN

To create a new file DSN follow the following steps:

  1. Open the ODBC Data Source Administrator dialog box:
    • Go to the Start Menu
    • Choose Settings
    • Choose Control Panel
    • Select the ODBC icon
  2. . Select the File DSN tab.
  3. Choose Add.
  4. Select the driver for which you want to set up a data source, and then choose Next.
  5. Type a name for the file that will contain the connection information. Once created, this name will appear in the Select Data Source dialog box. The extension .dsn is automatically appended to the name that you type. When you have finished typing the name, choose Next.
    • Review the information you have entered. If everything is correct, choose Finish. If you want to make changes, choose Back.
    • Follow the instructions for the Create a New Data Source wizard or the dialog box that is displayed. For help with these dialog boxes, choose the Help button.

If you've created a file DSN for a server-based database (like Oracle), you will be rompted with the login dialog box for the database server. The values you enter into the login dialog box are used to build the connection string stored in the file DSN. If you specify a password in the login dialog box, you will be prompted for the password every time you log on to the database. If the account you use to log on to the database doesn't have a password, you won't be prompted for a password when you log on again.


OGDI (Open Geospatial Datastore Interface)

GeoGateway supports OGDI which is a similar technology to GeoGateway. Some of the formats supported by OGDI are:

  • VMAP
  • UVMAP
  • CIB
  • CADRG
  • ADRG
  • DCW

However ADRG CIB and CADRG are supported directly by GeoGateway and it is more efficient to read DCW files using DCWRead.

OGDI was developed by Global Geomatics and was formerly maintained as an open exchange technology by the III (Information Interoperability Institute).

The OGDI supports client-server where a direct RPC connection is possible and Global Geomatics supports an extension where there is a firewall between client and server. The remote OGDI data may be either a file or a server such as CubeSTOR from CubeWerx.

To open a remote OGDI data server, in the file selector click on 'Choose Other' and pick OGDI from the 'driver' list. Then enter a URL in the layer field.

For example enter

"gltp://www.globalgeo.com/vrf/i:/scenery/data/vm2alv2/texash"

The format of the URL is:

  • "gltp:" specifying "Geographic Library Transfer Protocol".
  • After the double slash is the URL of the server(www.globalgeo.com).
  • After the single slash is the OGDI driver name (vrf).
  • The final part is the data name (i:/scenery/data/vm2alv2/texash).

For remote CubeSTOR data the URL could be:

"gltp://alpha.cubewerx.com/cwogdi/test/test@CWDEV&attributes"

For local data the URL could be:

 "gltp:/rpf/f:/polk/cib5/rpf"

Notice, there is no server name in this case.

Opening CIB data (or any other OGDI local data) by specifying the URL is equivalent to opening the file as specified for CIB data above.

There is an optional part to the OGDI URL specifying the actual layer to open.

For example:

 "gltp://alpha.cubewerx.com/cwogdi/demo/demo@demo&attributes::Line:POLBNDL_1M@BOUNDARIES"

specifies to open the line layer POLBNDL_1M from the BOUNDARIES coverage (group of layers) from the CubeSTOR server.

The error "Unable to connect to dispatcher gltpd" means that OGDI could not make a two-way connection to the server.


ORACLE

Geogateway supports Oracle8i tables/views for read/write access. Oracle Spatial and GeoImage datatypes are also fully supported for read/write access.

Open an Oracle table/view

To open an Oracle table/view from the File menu, select Open. Then, from the OpenFile dialog window, press the Choose Other button. Finally, from the Choose Other dialog window, select from the Driver edit box "Oracle" and submit as it is indicated a name for an Oracle table/view, a database connection name, a user name and finally a user password in the appropriate edit boxes. The name of the Oracle table/view can either be input manually in the appropriate edit box or choosen from the Layer List dialog window by pressing the Choose button of the Choose Other dialog window. If the name of the table/view is entered manually and the user is not the owner of the table/view, the name of the owner of the table/view must be entered first following by a period and then, the name of the table/view.

The database connection name, user name and user password can be declared and set in 3 different environment variables in the user's system. In order to be read by Geogateway, the environment variable names for the database connection name, user name and user password must be respectively defined as ORADATABASE, ORAUSER and ORAPASSWD. Once those variables set, the user will have only to submit an Oracle table/view name in the Choose Other dialog window.

Field Selection

In the process of openning an Oracle table/view, attributes of the Oracle table/view can be also chosen. If the All Fields checkbox of the Choose Other dialog window is checked, all attributes of the table/view will be automatically selected and consequently displayed and accessible from the application. However, if the checkmark is removed, the names of all attributes will be displayed in the list box of the Choose Other dialog window and only the one(s) chosen by the user from the list box will be displayed and accessible from the application.

However there are a few restrictions regarding field selection. If a field name is specified in the Table/View edit box of the Choose Other dialog window, as discussed below, this field will be loaded, displayed and accessible from the application even if that field has not been selected by the user from the list box. If the table/view contains more than one Spatial or GeoImage field and one of these field names has been specified in the Table/View edit box, only the specified one will be loaded into the application even if another Spatial or GeoImage field has been selected from the list box.

Fixed Extents Selection

In the process of openning an Oracle table/view, the user can specify a zone of interest (extents) which will open a table/view (layer) based on these extents. In order to do it, check the Fixed Extents checkbox of the Choose Other dialog window and enter manually 2 sets of lat/long coordinates in the appropriate following edit boxes: UpperLeftX, UpperLeftY, LowRightX and LowRightY.

If a layer is present in Focus/GeoGateway, the extents of this layer can be chosen as a zone of interest to open a new table/view (layer). In order to do it, check the Fixed Extents checkbox of the Choose Other dialog window and that's it. Focus will fill automatically the appropriate edit boxes with the extent coordinates of the present layer.

To visualize Oracle Spatial field

In order to visualize an Oracle Spatial field, an Oracle table/view containing a Spatial field must be opened. There are different ways to open such a table:

  1. Method of selection with only one Spatial field in the table/view:

    2. Manually enter in the table/view edit box of the Choose Other dialog window the name of the table/view containing a Spatial field and press OK.

  2. Method of selection with more than one Spatial field in the table/view:

    3. Manually enter in the table/view edit box of the Choose Other dialog window the name of the table/view followed by S= and the name of the Spatial field and press OK. e.g. scott.cities S=roads, where scott is the name of the owner of the table/view, cities the name of the table/view and roads the name of the Spatial field

  3. From the Layer List dialog window, choose a table/view name followed by S= and the name of the Spatial field and press OK.

Following the table/view selection, Geogateway will automatically display in the map area the graphical contents of the table/view spatial field.

To visualize Oracle GeoImage field

In order to visualize an Oracle GeoImage field, an Oracle table/view containing a GeoImage field must be opened. There are different ways to open such a table:

  1. Method of selection with only one GeoImage field in the table/view:

    2. Manually enter in the table/view edit box of the Choose Other dialog window the name of the table/view containing a GeoImage field and press OK.

  2. Method of selection with more than one GeoImage field in the table/view:

    3. Manually enter in the table/view edit box of the Choose Other dialog window the name of the table/view followed by G= and the name of the GeoImage field and press OK. e.g. scott.usimage G=images, where scott is the name of the owner, usimage the name of the table/view and images the name of the GeoImage field

  3. From the Layer List dialog window, choose a table/view name followed by G= and the name of the GeoImage field and press OK.

Once opened, select from the Map Panel the layer name (table/view) containing the GeoImage field and then from the main tool bar press the View Attribute icon. From the View Attribute window, select the column containing the GeoImage field. This column is easily recognizable from the others since each column's cell contains a picture of a photo camera. Pick one of the selected column's cells and select from the contextual menu choice, the Add to Area item.

Another way to open a GeoImage is based on the selection of the GeoImage's footprint. Once an Oracle table/view loaded and the View Attribute window of the layer (table/view) opened, select one of the footprints (polygon representing the edge of the geoImage) in the map area. In order to choose a footprint, first select from the Map Panel the layer name, then from the main tool bar press the Arrow Selector and finally, with the mouse cursor, choose the desired footprint. Once selected, one of the View Attribute's records will be highlighted indicating to which GeoImage belongs the footprint. From the highlighted row, select the GeoImage field cell and from the contextual menu choice, the Add to Area item.

Longitude and Latitude fields

If the Oracle table/view contains fields called Long and Lat or x and y, Geogateway will automatically assign metadata to the layer to indicate these fields are to be used for the point location.

Export a file from the disk to Oracle

To export a file from the disk to an Oracle database, choose from the File menu the Utility item and from the Utility menu, the Translate (Export) item. From the Translate (Export) dialog window press the Source File Select button then choose a file from the Open File dialog window and press the Open button to confirm your choice. Next, press the Destination File Select button and from the Open File dialog window press the Choose Other button. From the Choose Other dialog window, add a name for an Oracle table (to be created) under the table/view edit box, a database connection name, a user name and finally a user password in the appropriate edit boxes and then press the Ok button. From the Output Format list box, pick the "ORA:Oracle" format, and from the Exportable Items View list box select the "VEC Segment" option and select one vector layer then press the ADD and Export buttons.

It should be noted that GeoGateway can only translate one vector layer in an Oracle table at a time.

As mentioned above, if the ORADATABASE, ORAUSER and ORAPASSWD environment variables have been declared and set, the user will have only to enter a table name in the Destination File edit box a table name.


Ordnance Survey: BaseData.GB (.NTF)

BaseData.GB is defined as a geometrically structured "link and node" database. Features are represented as points, that are fixed positionally by one coordinate pair, and lines, a direct connection between two pairs of coordinates. These determine the geometric or positional characteristics of the data. They may, for example, describe the course of a road by position and orientation (line) or the position of a dual carriageway roundabout (point).

BaseData.GB(NTF v2.0 level 3) are supported by the GeoGateway library for import and view.

Structure of features

The structure of each different feature is as follows:

1. Point Feature:
. a Point Record [POINTREC] 15;
. a Geometry Record [GEOMETRY1] 21;
. an associated Attribute Record [ATTREC] 14, which contains
  a measurement for variable sized symbols.
2. Line Feature:
. a Line Record [LINEREC] 23;
. a Geometry Record [GEOMETRY1] 21,and maybe one or more
   continuation Records[CONTREC] 00 to extend the Geometry Record.
. Geometry Continuation Records
. an associated Attribute Record [ATTREC] 14
4. Text Feature:
. a Text Record [TEXTREC] 43;
. a Text Position Record [TEXTPOS] 44;
. a Text Represenration Record [TEXTREP] 45
. a Geometry Record [GEOMETRY1] 21.
. an associated Attribute Record [ATTREC] 14

Coordinate referencing system

All coordinates within the data are expressed as strings of six numeric characters. Leading zeros are present to complete the six characters.All coordinates are expressed in metres and are measured from the local origin, which is the south-west corner of the 100 km by 100 km square.To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the south-west corner of the 100 km by 100 km square. The south-west corner coordinates are contained within the {X_ORIG} and {Y_ORIG}fields of the Section Header Record ([SECHREC]).

See UK National Transfer Format (.NTF) for information on georeferencing.


Ordnance Survey: Boundary Line (.NTF)

Boundary-Line is a structured vector dataset. Each polygon contains a seed with its attributes; the links that represent its boundaries carry explicit pointers to the seed. Three vector layers may be used to display NTF file's four data set:

  1. line
  2. polygon
  3. complex polygon
  4. collect

Boundary-Line(NTF v2.0 level 3) are supported by the GeoGateway library for import and view.

Structure of features

The structure of each different feature is as follows:

1. Line Feature:
. a Geometry Record [GEOMETRY1] 21
. Geometry Continuation Records
. an associated Attribute Record [ATTREC] 14
2. Polygon Feature:
. a Polygon Record [POLYREC] 31
. a Geometry Record [GEOMETRY1] 21
. a Chain Record [CHAINREC]24 and and maybe one or more
  continuation Records[CONTREC] 00 to extend the Chain Record
. an associated Attribute Record [ATTREC] 14
3. Complex Polygon Feature:
. a Complex Polygon Record [CPOLYREC] 33 and and maybe one or more
  continuation Records[CONTREC] 00 to extend the CPoly Record
. an associated Attribute Record [ATTREC] 14, maybe one or more
   continuation Records[CONTREC] 00 to extend the Attribute Record
4. Collect Feature:
. a Collect Record [COLLECTREC] 34
. an associated Attribute Record [ATTREC] 14,maybe one or more
  continuation Records[CONTREC] 00 to extend the Attribute Record

Coordinate referencing system

Coordinate values and the number of coordinate pairs in a feature are transferred in the Geometry Record [GEOMETRY1]. All coordinates are expressed as strings of six numeric characters for the Eastings and Northings. All coordinates are measured from the local origin, which is the south-west corner of the 25 km by 25 km tile.To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the SW corner of the 25 km by 25 km tile. The SW corner coordinates are contained within the {X_ORIG} and {Y_ORIG} fields of the Section Header Record [SECHREC].

See UK National Transfer Format (.NTF) for information on georeferencing.

Bounding-Line 2000 the differences:

.. Removal of feature coding
.. Removal of tile based supply. The data will be supplied by named files
   instead of the 25km*25km numbered tiles.
.. Removal of polygon seeds
.. Addition of area codes at the administration level
.. Addition of explicit administration and/or voting area relationships
.. Removal of explicit foreshore areas

Others change:

.. Each polygon carries ID, HA attributes
.. Each link(line) carries LK-ID, FC attributes
.. Each collection carries: AI, NM, OP, AC, NB, NA, TY attributes
.. All coordinates are expressed as string of eight numeric characters
   for the eastings and eight numeric characters for the northing(before,
   this number is six), where appropriate, leading zeros are present to
   complete the eight characters.

For more detail, see Bounding-Line 2000 User Guide


Ordnance Survey: Meridian (.NTF)

Meridian data is supplied in the British Standard national format common to all Ordnance Survey's digital map data products;namely NTF, and is transferred in Level 3 as variable length records.Meridian (NTF v2.0 level 3) are supported by the GeoGateway library for import and view.

Meridian data within each layer are supplied as vector data, in a link and node structure. Geographical features are represented as data entities either as points or lines. Points are fixed positionally by one coordinate pair, e.g. a railway station. Lines are fixed positionally by a series of connected coordinate points to represent linear map features such as roads, railways, etc. Points and lines within the data model determine the geometric (positional) characteristics of the data.

Structure of features

The structure of each different feature is as follows:

1.Point Feature
. POINT RECORD [POINTREC]
. GEOMETRY RECORD [GEOMETRY1]
. ATTRIBUTE RECORD [ATTREC]
2.Line Feature
. LINE RECORD [LINEREC]
. GEOMETRY RECORD [GEOMETRY1] and GEOMETRY CONTINUATION RECORDS
. ATTRIBUTE RECORDS [ATTREC]
3.Name Detail
. TEXT RECORD [TEXTREC]
. TEXT POSITION RECORD [TEXTPOS]
. TEXT REPRESENTATION RECORD [TEXTREP]
. GEOMETRY RECORD [GEOMETRY1]
. ATTRIBUTE RECORD [ATTREC]

Coordinate referencing system

Coordinate values and the number of coordinate pairs in a feature are transferred in the [GEOMETRY1] NTF record. All coordinates within the data are expressed as strings of five numeric characters. Leading zeros are present to complete the five characters.All coordinates are measured from the local origin, which is the south-west corner of the tile.To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the south-west corner of the tile. The south-west corner coordinates are contained within the {X_ORIG} and {Y_ORIG} fields of the Section Header Record ([SECHREC]).

See UK National Transfer Format (.NTF) for information on georeferencing.


Ordnance Survey: AddressPoint (.NTF)

ADDRESS-POINT version 2.0 is an Ordnance Survey data product that provides a National Grid coordinate and a unique reference for each postal address in Great Britain. ADDRESS-POINT are supported by the GeoGateway library for import and view. BaseData.

ADDRESS-POINT provides:

. The correct postal address which will allow users to address
  mail properly as required by Royal Mail.
. A National Grid reference which will enable users to locate
  precisely the geographical position of the address and relate
  it directly to Ordnance Survey Land-Line's data.
. An Ordnance Survey ADDRESS-POINT reference (OSAPR)
  which gives a unique reference code for every delivery point.
. A status flag, which indicates the seed type, positional
  quality, physical status and the address match status applied
  to each delivery point.
. Change indicators to classify and record update.
. A source currency indicator to record the currency of the
  Royal Mail Postcode Address File (PAF).

Section Header Record [SECHREC]

This mandatory record starts a section. It contains information and parameters essential for understanding, interpreting and processing some of the fields within the data. It establishes the unit of measure for X and Y coordinates, origins and other constants.

Point Record [POINTREC]

This contains a feature serial number which is unique within any one section. It also details the change type and change date for a delivery point.

Geometry Record [GEOMETRY1]

This record contains the coordinate position of the delivery point identified in the previous Point Record. Attribute Record [ATTREC] The Attribute Record gives the attributes of the delivery point, for example the OSAPR, building number, thoroughfare name, post town name, postcode and status flag. This logical record will normally have one or more continuation records to transfer all the attribute information.

See UK National Transfer Format (.NTF) for information on georeferencing.


OSCAR Vector File (.NTF)

The OSCAR product family are supplied as vector data, in a "link and node" structure where links are road centrelines and nodes are intersections of links with attributes attached to each feature. Each road is classified by means of a feature code, with unique identifiers to enable you to create consistent references between releases of OSCAR.The links within OSCAR Traffic-Manager, OSCAR Route-Manager, and OSCAR Network-Manager have all been filtered thereby reducing data quantities while retaining a realistic representation of the road network. The retention of the nodes in true National Grid position ensures a high level of physical precision within the roadway

OSCAR (NTF 2.0,level 3) file are supported by the GeoGateway library for import and view.Two vector layers may be used to display NTF file's two data set:

  1. point
  2. line

Structure of features

The structure of each different feature is as follows:

1. Points feature consist of:
. a Point Record [POINTREC] 15;
. a Geometry Record [GEOMETRY1] 21;
. an associated Attribute Record [ATTREC] 14.
2. Lines feature consist of:
. a Line Record [LINEREC] 23;
. a Geometry Record [GEOMETRY1] 21;
. and maybe one or more Continuation Records[CONTREC] 00 to extend
   the Geometry Record.
. an associated Attribute Record [ATTREC] 14.

Coordinate referencing system

The eastings {X_COORD} and northings {Y_COORD} are separate fields and therefore coordinate pairs can be split across records, although the integrity of the fields themselves are not compromised. All coordinates are measured from the local origin, which is the south-west corner of the tile. To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the SW corner of the tile. The SW corner coordinates are contained within the {X_ORIG} and {Y_ORIG} fields of the Section Header Record [SECHREC].

See UK National Transfer Format (.NTF) for information on georeferencing.


OTHG Vector file (.OTG)

The OTHT Gold formatted product is designed to conform to the Canadian Department of National Defence ITG MTF standard format. The OTHT contact report format allows for reporting significantly more information than that which is available from the analysis of spaceborne SAR images. The OFW OTHT Gold format product is therefore a simplified version of the complete product. The product consists of a message header, the message body and a message termination sequence. The fields in a message set are separated by field markers (/). Fields are categorised as mandatory and optional. If there is no information for a specific fields, it may be omitted, although the field delimiters must be retained. Each line can be maximum 69 characters long. Fields can not be split between lines.

The OFW target detection message body in OTHT Gold format is a contact report that consists of a minimum of two lines of data. The first line is used to identify the contact, and starts with the identifier CTC. The following line is used to indicate a contact's position, time of position and other relevant information about the track. This line starts with POS as an identifier. In the OFW implementation, the probability of a target being a ship, the wake quality and course and speed are provided in comment or remark lines. These lines are identified with the sequence RMKS in the first field of the line.

Georeferencing information is supported also.


PAMAP

A PAMAP database typically consists of four files which must be kept together in same directory in order to be accessed. The .HDR file contains georeferencing information, PCTs, and LUTs. The .RFL file contains the raster data. The .VFL file contains vector data. The .DFL file contains attribute data.

PAMAP files are supported for import, and export, but not for live linking.

The GeoGateway model prohibits the creation of new PCTs and LUTs even though the PAMAP file format could support it. The model also prohibits the creation of multiresolution raster layers within a single database even though the PAMAP format could support it.

The following subtopics describe the limitations for each data type in more detail.


Raster Data

A PAMAP database can have zero or more raster (image) layers. In a PAMAP database, each layer covers the same area on the earth but each layer may be a different resolution. In order to comply with the GeoGateway data model, the width of the database is reported as the width of the highest resolution layer. The height of the database is reported as the height of the highest resolution layer. When reading multiresolution databases, applications should access all layers as if they were of the highest resolution. GeoGateway automatically replicates the pixel data for lower resolution layers.

PAMAP raster layers have either 1, 2, or 4 bytes per pixel. The mapping to GeoGateway is as follows:

       PAMAP Size ->   GeoGateway ->   PAMAP Size
       1               8U              1
       -               16S             2
       2               16U             2
       4               32R             4

Currently, PAMAP raster layers can only be written once. When a PAMAP database is created or a raster layer is added, the layer can be written and rewritten in any order. Once the file is closed though, existing layers can only be read.

PAMAP databases further distinguish a raster layer as being either a "Polygon Cover", "Reference Cover", or "Surface Cover", GeoGateway can read all cover types. Only surface covers can be created and written to. The GeoGateway model prohibits the creation of new raster layers other than at the highest resolution currently in the database.


Georeferencing

PAMAP databases support all common datums and projections supported by PCIDSK files. All raster and vector layers have the same georeferencing in a PAMAP database.


PseudoColour Tables (PCT)

PCTs are referred to as Colour Look-up Tables (CLUTs) using the PAMAP terminology. CLUTs can have 1 to 256 entries and can be one of three types: RGB100 where the red, green, and blue intensities are in the range 0 to 100; RGB256 where the intensities are in the range 0 to 255; and HLS100 where the hue, lightness and saturation intensities are in the range 0 to 100.

Currently, only CLUTs of the RGB256 type with 256 entries are supported. The results of reading/writing other types is undefined.

Existing CLUTs can be read/written. The GeoGateway model prohibits the creation of new CLUTs.


Lookup Tables (LUT)

LUTs are referred to as Threshold Look-up Tables (TLUTs) using the PAMAP terminology. TLUTs can have 1 to 256 entries and have floating point values dividing each class or theme.

Currently, the only supported TLUTs are those with 256 entries and thresholds running sequentially from 0 to 255 and class/theme values in the range 0 to 255. The results of reading/writing other types is undefined.

Existing TLUTs can be read/written. The GeoGateway model prohibits the creation of new TLUTs.


Vectors (VEC)

PAMAP databases support points, polylines, and whole polygons. Currently, there is no support for topological polygons.

Each shape has a number of system defined attributes as well user defined attributes. Attributes can be floats, doubles, integers or strings.

New layers can be created in a PAMAP database through GeoGateway. The following keywords in the options string controls the type of layer created:

Point - creates a point layer
Vector - creates a polyline layer
Polygon - creates a polygon layer

The keyword "LEVELxx" crates the layer on a specific level. For example, "Point LEVEL23" would create a point layer on level 23 of the PAMAP database. In the absence of keywords in the options string, the default behaviour is to create a polygon layer on the next available level.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

Paradox

See DAO.


PCIDSK (PIX)

PCIDSK is fully supported by the GeoGateway library. It is the only file format which currently allows "adding" segments, and one of the few which allows data description fields to be extracted and saved to the file.

The PCIDSK format supports files sizes of greater than 2 GB, subject to certain system restrictions.

A variety of database maintenance operations for PCIDSK files can be performed from the Works File Utility, often found as the "Utility..." entry in the File menu of PCI applications. A complete format specification for the PCIDSK format can be found in the PCIDSK Database Reference Manual distributed with EASI/PACE.

Export of PCIDSK files is supported. These files are exported with a type of "PIX".

The generated file will (as usual) have all images channels of the same type which will be the "largest" of the input image data types. Also, bitmap, vector, lut and pct segments will be created as required. Georeferencing is transferred.

The following options strings can be provided to control the raster format of the resulting file.

  • "BAND": This produces a band interleaved file. This format is the default.
  • "PIXEL": This produces a pixel interleaved file.
  • "FILE": This produces a PCIDSK file (header), plus a separate external file for each raster channel.
  • "TILED[nnn] [compression] [ENCRYPT=key]": This produces a tiled file. If the TILED keyword is followed by a number, then this will set the tile size, otherwise a tile size of 127x127 is selected. Normally the tiles are stored uncompressed, but if the JPEG, or RLE keyword is added (separated by a space), then the tiles will either be JPEG (lossy) compressed, or run length encoded. Example values would be "TILED", "TILED512 JPEG", and "TILED RLE". If the ENCRYPT=key option is added, the image data for the file will be kept in encrypted form, based on the key given. This key will have to be supplied when the file is used in the future to unencrypt the data. An example would be "TILED RLE ENCRYPT=password".

The choice of layout is primarily based on performance. BAND interleaved stores all the data for one band together, and gives superior performance when not all bands are being accessed at all times. PIXEL interleaved stores data the data for all bands at a particular pixel together, and may give somewhat improved performance when all bands are being utilized at once. FILE interleaved is similar to BAND interleaved, but the image channel data is stored in external files (one file per band).

Tiled files have the image organized in many square subimages, and can be much faster to access when only a subarea is being extracted, such as in file viewing. Tiling is also the only format which supports compression formats, with the default being no compression. JPEG compression is a lossy compression, and is normally suitable for continuous images such as airphotos. RLE (Run Length Encoding) compression is lossless, but will only give good compression for images where long sequences of pixels have the same value, as typically happens in pseudo-coloured, or thematic images.

The PCIDSK file format is described in detail in the "PCIDSK Database Reference" manual. This is typically called dbref.ps on the PCI documentation CD, and may be available on the PCI ftp site at ftp://ftp.pci.on.ca/pub/doc_v60/prog/dbref.ps.Z, or a similar location.

See Also


PCX - ZSoft Raster Format

PCX file format is a raster file format used with PC Paint Brush from ZSoft and also used in other Windows applications.

Geogateway supports the image variants which have 1, 2, 4, 8 or 24 bits per pixel. Rasters with 1, 2 and 4 bits per pixel are mapped to 8 bits per pixel in Geogateway. Rasters with 24 bits per pixel are mapped to rasters with three channels in Geogateway.

Export of PCX files is supported. PCX files are exported with a type of "PCX".

Geogateway can only create PCX files using one or three channels.

Geogateway creates 8 bit per pixel rasters if the raster has one channel or 24 bit per pixel if the raster has three channels.


PLT (Geosoft Plot File)

Geosoft Plot Meta Files, in the form of .plt/.att files, are supported by the GeoGateway library for both read and write with RST support, with some limitations listed below. GeoGateway will generate files that conform to release 2.1 of the format specification, and can read files of any version up to release 2.1

All Graphical Entities from the .PLT file are imported, and a RST is generated while reading. Each entity is given a REPCode that points to an entry in the RST. GeoGateway automatically generates 3 attributes that will contain representation information needed by the RST:

  REPCode       (Integer) Index to a REPCode in the generated RST.
  Angle         (Double)  Orientation for Texts and Symbols.
  TextString    (String)  Text value.

Lines, Polylines, and Polygons are imported directly. Circles (and arcs) are emulated with line segments that cover 3 degrees each (120 segments in one complete circle). When Symbols, Texts, and PolySymbols are imported some of their representation attributes (Text font, slant, symbol number, etc.) are very likely to be lost, since they cannot be remapped directly by GeoGateway.

Old style plot files that contain only Pen Number references are also supported. In these cases, an uninterrupted set of Pen-Down moves forms a Shape, and its REPCode attribute is the Pen Number. GeoGateway will assign an arbitrary colour for each pen in the RST.

The projection on import is set to "METRE". The paper coordinates (millimetres) will be converted to ground coordinates (metres) using the scale in the PLT file. If this information is not present, then a scale of 1:1000 is assumed (1 paper mm = 1 ground m) as stated in the Geosoft specifications.

In write mode, vertices and representation attributes (if a RST is available) are exported, however, GeoGateway attribute fields cannot be exported. The PLT file is generated with the default scale of 1:1000 and the original GeoGateway projection (if present) will be lost. The plot extents are automatically set to be the complete layer extents.

Representation attributes from the RST are remapped to their closest Geosoft equivalent. The best results are obtained with RSTs that have been generated by this same translator while reading.

See Also

GXF, GGF


PPM/PGM/PBM (PPM)

Raw PPM, PGM, and PBM files are simple raster formats supported by the GeoGateway library. ASCII formatted PPM, PGM, and PBM files are not supported. These files are an interchange format used by the popular `pbmplus' file interchange utilities.

  • PPM: RGB format, only 24-bit supported.
  • PGM: Greyscale, only 8-bit supported.
  • PBM: Bitmap, all supported.

PPM, PGM, and PBM files have no auxiliary information such as georeferencing, LUTs, or PCTs; however, georeferencing will be exported in an .aux file.

These formats are supported for read, write, and update. The PPM and PGM files can be accessed with the LINK program.

Export of PPM files is supported. These files are exported with a type of "PPM".

The provided data must match one of these three configurations:

  • 1 Channel: PGM Greyscale.
  • 3 Channels: PPM RGB.
  • 1 Bitmap: PBM Bitmap.

Georeferencing information will be placed in an ".aux" file in the same directory.


Raw Binary Image Format

The GDB library has a facility for reading and writing imagery in user described raw files. Some applications (such as ImageWorks) include interactive dialogs for describing the layout of the data. This description is then saved to a .aux file in the same directory as the raw data, allowing automatic use of the same file in the future without redescribing it.

Users can also prepare .aux files by hand, or with scripts. Furthermore, much of the image layout information that can be provided in the .aux file can also be supplied via a complex file naming convention if so desired.

Export of Raw Binary files is supported. These files are exported with a type of "RAW".

The default image interleaving is band sequential, but this can be overridden with the following option values during creation:

  • "BAND": The default band sequential.
  • "PIXEL": The image data is pixel interleaved.
  • "LINE": The image data is line interleaved.
  • "TILEDnnn": The image data will be stored in tiles of the specified size. If no size is provided a default size is assumed.

Georeferencing (or Projection), and file layout information will be written to an auxiliary file, which has the same name as the data file but with the extension ".aux".

The generated files may contain any image data types, but may not contain LUTs, PCTs, vectors, or bitmaps.


Raw .aux Format

The .aux file is a simple ASCII file used to store a variety of information about an associated target file. It is used to store all information about raw files (other than the image data itself). The following is an example of a fairly simple .aux file that would be called "test.aux".

 AuxilaryTarget: test.raw
 RawDefinition: 300 300 2
 ChanDefinition-1: 16U 512 2 600 Swapped
 ChanDefinition-2: 16U 180512 2 600 Swapped
 ChanDesc-1: Original DEM
 ChanDesc-2: Edited DEM
 MapUnits: UTM    11 S E000
 UpLeftX: 428720
 UpLeftY: 3734400
 LoRightX: 444080
 LoRightY: 3719040
 ProjParms: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 METADATA_IMG_2_NO_DATA_VALUE: 100

First, an .aux file describing a file must be in the same directory as the target file, have the same basename, but the extension .aux. In the above example a selection of the file test.raw would case GeoGateway to check for the associated test.aux file. If it finds it, the name of the raw file (test.raw) is checked against the AuxilaryTarget line in the .aux file. If the filenames are different, then the .aux file is ignored.

Therefore, the first line of any .aux file must be the AuxilaryTarget: entry with the value being the name (not including directory path) of the target file. Now imagine that there was a directory with the files test.001, test.002, and test.003. There can only be one test.aux in that directory so it is not possible to associate an .aux file with each of the files.

The .aux file consists of a series of entry names, and values. The entry name is the portion of a line before the first colon, and the value is everything after the colon. So above we see several entries including RawDefinition, ChanDefinition-1, and ChanDefinition-2.

 RawDefinition: pixels lines bands

The RawDefinition entry has three items as its value. They are the number of pixels, lines, and bands. They must be separated by white space, but otherwise the formatting is free form. If no ChanDefinition entries are provided, then the file is assumed to have zero header bytes, and to be band interleaved.

 ChanDefinition-n: data_type start_offset pixel_offset line_offset swap_flag

The ChanDefinition entry describes the data layout of a single channel, or band. The -n in the entry name indicates which band this description applies to. The data_type must be one of 8U, 16S, 16U, or 32R. The start offset is the offset in bytes to the first byte of data of the first pixel for this channel. The pixel_offset is the offset between the first byte of one pixel on a scanline, and the next pixel. The line_offset is the offset in bytes between the first pixel of one scanline and the first pixel of the next scanline. Lastly, the swap flag can either be Swapped (Intel/LSB) or Unswapped (Motorola/MSB).

 ChanDesc-n: description

The ChanDesc entry associates a channel description with a particular channel.

 MapUnits: projection_name

The MapUnits entry associates a projection/georeferencing system name with the file. It must contain at most 16 characters. Its interpretation is further described in the general projections description.

 UpLeftX, UpLeftY, LoRightX, LoRightY

These entries are used to provide the upper left and lower right corner coordinates in the indicated MapUnits.

 ProjParms: n1 n2 ... n17

This entry is used to supply additional parameters needed to define complex projections. The meaning of these parameters is not described here, but can be deduced by editing the projection parameters of a raw file and inspecting the values written to the .aux file.

 METADATA_layertype_layer#_metaitem: value

The METADATA entry can be used to associate the value "value" with the metadata item "metaitem" on the layer "layer#" of type "layertype".


Describing via Filename

Sometimes it is helpful to be able to describe the entire layout of a raw imagery filename via the filename. This allows any GeoGateway based utility to work with the raw image, whether it has interactive dialogs for raw describing the file or not. This also avoids the need to write an associated .aux file, which is impossible if the raw file is in a read-only directory, such as on a CDROM.

However, describing raw files via this filenaming syntax is not generally intended for interactive use. It is mainly useful in a scripting environment.

The naming convention for raw files is:

 RAW:::filename xsize ysize bands [offset {8U/16U/16S/32R} {PIXEL/LINE/BAND}]
   [*CHANNEL chan_num {8U/16U/16S/32R} offset pixel_off line_off
                                               [swapped/unswapped]]*

The absolute simplest file description would describe a band sequential file of 8-bit data that is tightly packed with no header. For example, the following would describe the file "raw.dat" as being three bands, 512 pixels by 512 lines.

 RAW:::raw.dat 512 512 3

A slightly more complex form can be used to define any file that could be read with IMAGERD. This adds the offset to the first byte of imagery, the data type and the interleaving mode. The following description defines the same file as the previous one, but it explicitly states that the offset to the first byte of imagery is zero; the data is 8-bit unsigned, band interleaved.

 RAW:::raw.dat 512 512 3 0 8U BAND

Many file organizations cannot be described this way. For instance, files with more than one data type, or files with spaces between bands or byte swapped multi-byte data, cannot be described this way. In these cases, it is possible to describe the layout of each channel. The following description defines the same raw.dat files as in the previous two descriptions. For each channel a data type, image offset, and swapping capability is provided.

 RAW:::raw.dat 512 512 3 *Channel 1 8U 0      1 512 unswapped
                         *Channel 2 8U 262144 1 512 unswapped
                         *Channel 3 8U 524288 1 512 unswapped

The offset is to the first byte of data in the channel, therefore channel two data starts at byte 262144 in the file. The second offset is from one pixel of data on the same scanline to the next pixel of data on the same scanline. The third offset is the offset from the beginning of one scanline to the beginning of the next. The swap flag indicates whether the data is in little endian order or not. Little endian byte order has the least significant byte of the word first, and is found on Intel and VAX machines. This is considered `swapped'. Big endian machines such as the Motorola and Sun are considered `unswapped'. The default is the native byte order of the current machine.

A more interesting example might be a 300x400 one-band file with little endian 16-bit unsigned data starting after a one block (512-byte) header.

 RAW:::testi2.dat 300 400 1 *Channel 1 16U 512 2 1024 swapped


Raster Product Format (RPF)

The RPF (Raster Product Format) has two subsets which are supported by GeoGateway for reading only. The CADRG and CIB datasets can be selected by selecting the "a.toc" file.

The CIB and CADRG formats support a dataset split over multiple files and directories. The projection information for RPF data is defined to use the WGS 84 datum.

RPF datasets consist of NITF tiles. These NITF files use Vector Quantization compression and tiling.

See Also

CADRG, CIB, NITF


RST - Works ASCII RST

The ASCII RST (Representation Style Table) files are supported by GeoGateway for read and write. The RST is used to attach a representation to vector layers in some Works applications. It consists of a list of representation styles (REPCode, integer value) with a graphical primitive and some parameters for each REPCode in the following format:

 GDBRST 1.0 Representation Style Table
 #
 Table <Table_descriptive_name>
 Symbols <Symbol_dataset_filename>
 Groups
 <GroupId>, <Description>
 <GroupId>, <Description>
 ...
 ...
 <GroupId>, <Description>
 Repcodes
 <Repcode>,<Part_Number>,<GroupId>,<PrimId>,<Priority>,<Description>
               <Parameter_name1> = <Value>
               <Parameter_name2> = <Value>
               ...
               <Parameter_nameN> = <Value>
 <Repcode>,<Part_Number>,<GroupId>,<PrimId>,<Priority>,<Description>
               <Parameter_name1> = <Value>
               <Parameter_name2> = <Value>
               ...
               <Parameter_nameN> = <Value>
 ...
 ...
 EndTable

Export of Works ASCII RST files is supported. These files are exported with a type of "RST", if it is possible to acquire a representation table from the source layers. The RST file can only contain 1 layer.

Only one RST can be stored in each file and it is always in segment 1.

An empty text file may be produced if exported from a file that does not contain an RST.


SDTS DEM - Spatial Data Transfer Standard Digital Elevation Model (.DDF)

SDTS is The Spatial Data Transfer Standard. The purpose of the SDTS is to promote and facilitate the transfer of digital spatial data between dissimilar computer systems, while preserving information meaning and minimizing the need for information external to the transfer.

The Dataset of SDTS typically consists of a master directory and a data directory. Under these directory is a list of .ddf file which are Binary file and contain the data we need. They must be kept together in same directory in order to be accessed. To load these data, it is best to select the file with "CATD.DDF", but if any other file in the directory is selected, it will be opened properly.

The SDTS TVP & DEM format are supported by the GeoGateway library for import and view, but not for export.

Many vector layers are used to display the proper SDTS Module. Mainly there are four Layer types: Point Layer, Line Layer, Polygon Layer and Attribute Layer. In each layer, there are two types of attributes which can occur. The first are hardcoded attributes specific to the feature type, and the second are generic user attributes stored in a separate primary attribute layer.

THE SDTS DEM is either a single 16 bit signed integer band or a single 32 bit real valued band.

Georeferencing information is supported also.


SeaWIFS CEOS

The GeoGateway library supports the OrbImage distributed SeaWIFS CEOS format for read access. Orbital Image is the commercial data provider of imagery from the ORBVIEW-2 (SeaWIFS) satellite. This translator was written using example level 1B, and 2A datasets provided by OrbImage. At this time level 2B and other products from OrbImage in CEOS format are not supported.

OrbImage SeaWIFS data is distributed in a modified CEOS format, and normally consists of 8 or 9 16bit unsigned image bands. A dataset normally consists of five files with particular names.

  • rw-r--r-- 1 nadeau daemon 3612334 Sep 4 15:27 ANNOTATION
  • rw-r--r-- 1 nadeau daemon 32673846 Sep 5 10:29 IMAGE
  • rw-r--r-- 1 nadeau daemon 1536 Sep 4 15:26 LEADER
  • rw-r--r-- 1 nadeau daemon 360 Sep 4 15:27 NULL_VDF
  • rw-r--r-- 1 nadeau daemon 1440 Sep 4 15:27 VDF

In order to read a SeaWIFS CEOS dataset the user should select the file name IMAGE. If the ANNOTATION and LEADER files are not named appropriately then the metadata and GCPs will not be captured.

Per scanline orbital information stored in the ANNOTATION file is used to derive a set of 252 approximate GCPs, represented as a GCP segment. These can be used to do a low precision image correction using an application like GCPWorks. Note that thin-plate splines are generally more appropriate than polynomial modelling for the complex of warping SeaWIFS data into geocoded coordinates due to the large region of the world represented.

A variety of header information about the scene location, and acquisition date, orbit, and acquisition parameters is captured from the LEADER file as metadata on each of the image channels. All SeaWIFS related metadata names start with "Seawifs_".

The following are values for an example dataset:

 Seawifs_OrbitNumber:    74891
 Seawifs_StartTime: 19960813T173940,000
 Seawifs_EndTime: 19960813T174325,833
 Seawifs_SceneCenterTime: 19960813T174132,833
 Seawifs_SceneCenterLatitude:      33.76007781
 Seawifs_SceneCenterLongitude:     -89.02038286
 Seawifs_UpperLeftLatitude:      42.36399801
 Seawifs_UpperLeftLongitude:    -106.17848195
 Seawifs_UpperRightLatitude:      37.11662320
 Seawifs_UpperRightLongitude:     -68.82545473
 Seawifs_LowerLeftLatitude:      29.06083046
 Seawifs_LowerLeftLongitude:    -106.92808289
 Seawifs_LowerRightLatitude:      24.55428087
 Seawifs_LowerRightLongitude:     -74.88265287
 ACQUISITION_DATE: 1996/08/13 17:39:40

SeaWIFS data is also provided by NASA in the SeaWIFS HDF format for some scientific users. OrbImage ordering information can be found on the OrbImage web site, http://www.orbimage.com/.

See Also

SeaWIFS HDF


SeaWIFS HDF

The GeoGateway library supports the SeaWIFS level 1A HDF format distributed by NASA for read access on selected platforms.

The SeaWIFS HDF translation is implemented using NCSA/NASA support libraries; however, PCI has only ported these to selected Unix platforms. Therefore, this format is only supported on Solaris 2.x, IRIX, HP/UX, and Linux platforms.

A variety of header information about the scene location, and acquisition date, orbit, and acquisition parameters is captured as metadata. All SeaWIFS related metadata names start with "Seawifs_".

For example:

       Seawifs_OrbitNumber: 78853
       Seawifs_StartNode: Descending

When FIMPORT is applied to SeaWIFS data, a GCP segment containing up to 255 GCPs is created. Level 1A files are not geo-corrected so no projection definition is available, but the GCPs can be used with GCPWorks to do an approximate correction.

There is no support for updating or writing the NASA SeaWIFS format.

See Also


Siemens SICAD (SQD)

The GeoGateway library supports Siemens SICAD SQD vector files for import. To select an SQD file set, select the first file in the set. For example, this could be smartland.sqd.001. All the files of the form smartland.sqd.xxx will be read.

The only SQD types supported are: point (PG), line (LI), polyline (LY), arc (BO), circle (KR). Symbols (SY), free text (TX) and variable text (TA) are handled as points. Splines (SN) are handled as polylines. Areas (FL) are ignored. All other types are ignored.

Any SICAD georeferencing information is lost when importing SICAD files, and a units string of METRE is assumed.

SICAD SQD files must contain co-ordinates in decimal format. Within SICAD this can be achieved using the option "GVA=T" for the SQD export commands.

For example:

 Export from SICAD database:    GBGQEL ... GVA=T ...
 Export from SICAD image:       SQDOLD ... GVA=T


SPANS Binary Format (top/vtx/tbb)

GeoGateway supports the SPANS vector binary format files (top/vtx) for reading only. The binary point and table files (tbb) are supported for reading and writing. Where the vector layer has attributes in a tbb file, the attributes are also opened when the vector layer is opened. The vector layer may be opened by selecting either the top (topology) or the vtx (vertex) file. If the tbb file is selected from a top/vtx/tbb set, then only the attribute (tbb) portion is opened.

In SPANS a vector file set appears as one layer. In GeoGateway the separate topological layers are shown. That is a topological arc layer is shown as a node layer and an arc layer. A topological area layer is shown as a node layer, an arc layer and an area layer. When a topological layer is opened, the nodes are shown by default.


SPANS Quadtree (MAP)

SPANS quadtree format is the format for the Tydac SPANS products. The Tydac SPANS quadtree format is used by SPANS to store raster data as a matrix of variable sized square cells. This storage format results in finer cell resolution in the vicinity of boundaries and larger cell resolution where a finer resolution is not necessary. The total storage size of the data is reduced with this storage format for classified data.

The GeoGateway library supports SPANS quadtree files for read access, and they will have the extension .MAP.

The GeoGateway library supports SPANS quadtree files which are 8U and 16U.

Projection and georeferencing is not supported with this format.

A SPANS quadtree only contains one band.


SPANS Raster (RNH)

SPANS Raster format is the interchange format for the Tydac SPANS products. The Tydac SPANS raster format can store various raster data types including 8-bit unsigned, 16-bit signed, and 16-bit unsigned. The GeoGateway library supports SPANS Raster format for import and export. SPANS Raster header files have the extension .RNH.

The GeoGateway library supports SPANS Raster files which are 8U, 16U, 16S and 32R. SPANS Raster files which are 1-bit are supported as bit map segments. SPANS Raster files which are 32-bit are supported as 32R.

SPANS Raster files are supported by the LINK program. Projection and georeferencing information is supported on import and export for most projection and ellipsoid types; however, there are cases that do not translate between systems. Also, SPANS colour table files (.rgb extension) can be read and written.

Export of SPANS Raster files is supported. These files are exported with a type of "RNH".

One or more bands of 8-bit, 16-bit signed or 16-bit unsigned data may be exported. 32R data is exported as 16S.

Export of a single Bitmap segment is supported.

A file with the same basename as the header (.rnh) file will be created for each band exported. These files will be assigned the same file naming convention used within the SPANS products.

Most PCI projections can be exported to SPANS Raster file. No other auxiliary information is exportable.


SPANS Table File (TBA)

TBA is a database (attribute table) format associated with Spans VEC/VEH files or is a SPANS point dataset containing both coordinate data and attributes. It is supported for import and export by the GeoGateway library.

If the TBA file is a point layer, the georeferencing system information will be imported or exported from the TBA file.

TBA files are associated with VEC/VEH files and need not be directly read or written. Reading in a VEC/VEH file with an associated .tba file will read in the .tba file automatically. Similarly, writing out vectors to VEC/VEH format will produce a .tba file for the attributes.

Export of SPANS table files is supported. These files are exported with a type of "TBA".

Only one vector layer can be specified for export. A single TBA file will be created containing the attributes of the vector layer. All data types are supported except for integer lists. No vertex data is supported by this format. To export attribute and vector data, use the VEC/VEH format.

See Also


SPANS Vector Archive VEC/VEH

The GeoGateway library supports the SPANS Archive format for both read and writ e operations. The SPANS archive format consists of two files that have a common basename, and .VEC and .VEH extensions. The VEC file contains the actual data, whereas the VEH is the header file and describes the contents of the VEC file. In addition, there may be a .TBA file which contains the attribute records associated with the VEC/VEH file.

All data sections are supported for read operations; any corresponding TBA file will also be read in.

Export of SPANS Vector Archive files is supported. These files are exported with a type of "VEH".

Only one layer can be specified for export. A .VEC and .VEH file will be produced containing an ARC layer. Any attributes associated with the layer will be written out as a corresponding .TBA file.

Only ARCS data sections are written to the VEC file. This vector file is written out in ARC format, without topology, and composed of unclean lines. Any attributes associated with the arcs will be written out to the corresponding .TBA file.

If the exported layer is of type WHOLE_POLYGONS, the SPANS VEC file will contain areas represented as whole polygons. This is specified in the VEC file with the AREAS keyword. Any attributes associated with the areas will also be written out to the corresponding .TBA file.

SPANS Vector files may not be modified.

See Also


Spectral Library Files (.SPL)

Spectral Library format can be read by the GeoGateway library. Spectral Library format is used for USGS (U.S. Geological Survey) Spectroscopy Lab.

Spectral Library records are fixed format, 1536 bytes/record. Record number counting starts at 0. Binary data are in IEEE format real numbers and big-endian integers. Each record may contain different information according to the schema.

Detail description of the format can be found at: http://speclab.cr.usgs.gov/specpr-format.html http://speclab.cr.usgs.gov.


SPOTView GIS-GEOSPOT

The SPOTView GIS-GEOSPOT image format is a GIS ready image product distribution format used by Spot Image. The GeoGateway library supports the SPOTView 4.0 format now being distributed by some Spot Image distributor. The software has also been successfully used with some SPOTView 1.5 format datasets and ElViz (16 bit elevation product) datasets.

The SPOTView distribution format includes a number of auxiliary files organized in two levels of directories. In each subdirectory there should be one or more files ending in the extension .BIL, .REP and .HDR. The .HDR file contains georeferencing and structural information while the .BIL file contains just image data. The user must select the .BIL file in order to access the dataset.

Georeferencing information is handled for some projections; however, due to limitations in the available documentation, some Spot Image supported projections are not currently fully supported.

If the .clr file is present for an 8 bit image, then the values are read in to a PCT segment for the image.

Creation of SPOTView format is supported. The one option for export is WORLD. Specifying the WORLD option creates an ESRI World File containing the georeferencing. The default export adds georeferencing to the .hdr file.

If a PCT segment is selected for export, then a .clr file is created.


Socet Set Annotation

The Socet Set Annotation (.obj) file format is supported for read by GeoGateway. This format is used for vector and other annotation information intended to be overlaid on an image. Annotation files are produced by Socet Set (tm), as well as the Helava, and OrthoEngine Airphoto DEM software.

Annotation files contain vector data of five different types (Line, Polygon, Icon, Text, and Grid) which are each represented as distinct layers by GeoGateway. Icon and Grid features are transferred, but are essentially useless, since other GeoGateway based software does not recognize their meaning. Lines, Polygons, and Text are all carried over intact, but information about colour, line styles, fonts, and so forth are not preserved at this time.

The shapes are represented as having four, or five attributes:

  1. FeatureID: An identifier that can be used to group together a set of lines, or polygons that are intended to represent a single related feature.
  2. ElementID: An identifier numbering the shapes that go together to form a multi-shape feature.
  3. OBJType: The shape type (Line = 3, Polygon = 4, Icon = 5, Text = 6, and Grid = 7). Note that different shape types are already segregated into distinct layers with segment numbers the same as the OBJType value.
  4. TextString: This attribute occurs only in Icon and Text layers, and contains the icon filename or text string.

The dataset is normally represented in METRE coordinates since the true projection system is not currently recovered. Datasets that are actually in lat/long are recognized specially, and a projection of Long/Lat is assigned (with a default, but likely incorrect datum). The file format is supported only for import, not export nor update.


Socet Set DTM

The Socet Set DTM file format is supported for read by GeoGateway. This format is used to hold elevation products produced by Socet Set (tm), as well as the Helava, and OrthoEngine Airphoto DEM software.

These datasets normally consist of four files having the same basename and the extensions .dth (header), .dte (elevation data), .dtf, and .dtp. The .dtf and .dtp files are ignored. The user should select either the .dte or the .dth file to access the dataset.

The elevation is stored in the .dte file and is in four byte IEEE floating point format. When the data is read an attempt is made to establish the byte order of the data. However, if the imported image seems to be garbage it may be that the byte order was incorrectly established. In this case, the user can read the .dth header file in order to see how the .dte file is structured, and then use the IMAGERD PACE program to read in the .dte file based on what the .dth file reported.

The dataset is represented in METRE coordinates since the true projection system is not currently recovered. The projection is not stored in the .dth file.

The Socet Set DTM format is supported for import, linking, update in place, but not export.


Strategi Vector file (.NTF)

Strategi Data(NTF v2.0 level 3) are supported by the GeoGateway library for import and view. It is supplied by national cover, selected layer, regional cover, or 50km by 50km tiles.

Strategi is defined as a limited "link and node" structure. It contains points, lines and nodes. Nodes have pointers to lines (links) that join at the node but there is no explicit topology within the data. Similarly, there are lines (links) that enclose an area containing a point (seed), and again there is no explicit topology between the lines (links) and point(seed). Some points (seeds) are not contained within areas enclosed by lines (links). Four vector layers may be used to display its three data set:

  1. point
  2. line
  3. node
  4. text

Structure of features

The structure of each different feature is as follows:

  1. Point Feature:
    • a Point Record [POINTREC] 15
    • a Geometry Record [GEOMETRY1] 21
    • an associated Attribute Record [ATTREC] 14, which contains a measurement for variable sized symbols.
  2. Line Feature:
    • a Line Record [LINEREC] 23
    • a Geometry Record [GEOMETRY1] 21,and maybe one or more continuation Records[CONTREC] 00 to extend the Geometry Record.
    • an associated Attribute Record [ATTREC] 14
  3. Node Feature:
    • a Node Record [NODEREC] 16,and maybe one or more continuation Records[NODECONT] 00 to extend the Node Record
    • a Geometry Record [GEOMETRY1] 21
    • a Point Record [POINTREC] 15
    • an associated Attribute Record [ATTREC] 14
  4. Text Feature:
    • a Text Record [TEXTREC] 43
    • a Text Position Record [TEXTPOS] 44
    • a Text Position Record [TEXTREP] 45
    • a Geometry Record [GEOMETRY1] 21
    • an associated Attribute Record [ATTREC] 14

Coordinate referencing system

Coordinate values and the number of coordinate pairs in a feature are transferred in the [GEOMETRY1] NTF record. All coordinates within the data are expressed as strings of five numeric characters. Leading zeros are present to complete the five characters. All coordinates are measured from the local origin, which is the south-west corner of the 50 km by 50 km square. To convert coordinate data to full National Grid coordinates, add the coordinates of the feature to those of the south-west corner of the 50 km by 50 km square. The south-west corner coordinates are contained within the {X_ORIG} and {Y_ORIG}fields of the Section Header Record [SECHREC].

See UK National Transfer Format (.NTF) for information on georeferencing.


Sun Raster File (SUN)

Pseudocoloured, greyscale, and RGB Sun Raster files are supported by the GeoGateway library. This is a format generated by several Sun utilities, as well as many popular scanners.

Sun Raster files will have one or three image channels, and may contain a PCT or three LUTs depending on the configuration. Sun Raster files do not contain any georeferencing information, nor do they contain any fields describing the data. Sun Raster files can be created using the "New" menu selection in Works programs.

Export of Sun Raster files is supported. These files are exported with a type of "SUN".

Sun raster files may have any of the following configurations:

  • 1 Channel: Greyscale image.
  • 1 Channel + PCT: Pseudocoloured image.
  • 3 Channels + 0-3 LUTs: RGB Image with options LUTs.

No georeferencing information is exported with the Sun raster file.


Targa Raster File (TGA)

Two forms of Targa raster files are currently supported: uncompressed True-Colour, and Black & White formats. Colour-mapped images and any run-length encoded images are not supported at this time.

For Targa True-Colour files, 16, 24, and 32-bit images are all supported. A True-Colour file will appear as a three channel file; each file will contain either the Red, Green, or Blue component of the colour image. Black & White Targa files will appear as a file with a single channel.

Export of Targa files is supported. These files are exported with a type of "TGA".

The type of Targa file created is dependent on the number of channels specified.

  • 1 Channel: Greyscale image
  • 3 Channels 24-bit uncompressed True-colour image

No georeferencing information is exported with the Targa raster file.

Only True-Colour, and Black & White images are supported for write operations. The GeoGateway layer will only output True-Colour 24-bit files, which require as input three 8-bit channels. If a single channel is to be written out, the output will be a black and white Targa file.


TIFF (TIF)

Most common forms of TIFF/GeoTIFF files are supported by the GeoGateway library. In particular, it is possible to read TIFF B (Bitmap), TIFF R (RGB), TIFF P (Palette), and TIFF G (Greyscale). Files with none, LZW, JPEG, JPEG YCbCr or PackBits compression are supported, as well as those with some other compression schemes.

TIFF G files contain one channel of imagery; TIFF B files contain a single bitmap; TIFF P files contain a single channel of imagery and a pseudocolour segment. To properly view the image, it is necessary to load both the imagery and the segment, and place the display in pseudocolour mode. TIFF R files contain three image channels (RGB).

TIFF files do not support LUTs. No descriptive data is extracted from the TIFF file, nor is any written back.

Georeferencing information in GeoTIFF format can be written to, and extracted from TIFF files. GeoTIFF is a standard being widely adopted in the geomatics industry. PCI's support includes UTM, State Plane, Geographic, Lambert Conformal Conic, Transverse Mercator, Mercator, and Oblique Mercator as well as some other projections. Images with GeoTIFF georeferencing including a rotation are also supported.

If GeoTIFF information is not available, but an ESRI style TIFF world file is (with an extension of .tifw or .tfw), then it will be read for georeferencing information. However, the map units will always be set to METRE or LON/LAT, since the world file does not contain the projection information. A LON/LAT projection will be assigned if the offset is in the range of -180 to 190 and -90 to 90. The user of rotation coefficients in the world file is supported in GDB.

Also MapInfo style georeferencing is supported. MapInfo uses a .tab to store the projection definition and image georeferencing. The .tab file will have the same base name as the TIFF file.

Any uncompressed TIFF file that can be read, can also be written to; however, this is not true of compressed TIFF files which are read only.

The Tagged Image File Format (TIFF) was designed to be an extendible, all-purpose standard for image interchange. A TIFF file consists of an image with a list of information tags describing the image. A variety of image orderings is possible using TIFF files, as well as various types of compression. The TIFF format is extendible, because new information tags can be added at will; TIFF file readers are required to ignore tags they do not understand.

Because it is realistically impossible for a TIFF reader to read all possible TIFF format files, a small number of TIFF subset classifications have been developed. Requirements for reading and writing these classified files have also been developed.

Relevant classes are TIFF B (Bilevel or Bitmap), TIFF G (Grey level), TIFF P (Palette or Pseudocolour), and TIFF R (RGB).

The supported classes have a variety of possible compression schemes of which JPEG, LZW, PackBits, CCITT 3 Fax, and CCITT 4 Fax are known to work. PCI's TIFF support includes 16bit signed, and unsigned data as well as 32bit floating point in addition to the common 1 and 8 bit files.

The following are the valid configurations possible for TIFF.

  • 1 Channel: Results in a TIFF G or greyscale file.
  • 1 Channel + PCT: Results in a TIFF P or Pseudocoloured file.
  • 3 Channels: Results in a TIFF RGB file.
  • 1 Bitmap: Results in a TIFF B or bitmap file.
  • 4+ Channels: Results in a TIFF RGB file with additional data bands.

Georeferencing information is exported in GeoTIFF format by default.

The following values of options are available to select different compression schemes (note that LZW is no longer supported for creation due to Patent concerns):

  • NONE: No compression, also selected if FOPTIONS is blank.
  • PACKBITS: Macintosh PackBits format.
  • FAX3: CCITT Fax 3, only suitable for bitmaps.
  • FAX4: CCITT Fax 4, only suitable for bitmaps.
  • JPEG: JPEG compression

Normally TIFF files are written as a single image; however, with the TILED option the TIFF file can be written out as a series of smaller image tiles. This can be useful for faster localized loading of the resulting TIFF file. For instance an option value of "TILED256" would generate an image split into 256x256 pixel tiles.

 option = "TILED256"

It is also possible append the attribute WORLD to the option value, separated from other text by a space, in order to request that an Arc/Info style TIFF World file be generated.

 option = "WORLD"          | Uncompressed with World file
 option = "PACKBITS WORLD" | PACKBITS Compressed with World

Also an attribute option of MAPINFO can be used to create a MAPINFO .tab file which MapInfo uses to store the georeferencing information.

 option = "PACKBITS MAPINFO" | PACKBITS with MapInfo file for georeferencing

By default, GeoTIFF information is written to every TIFF file created. Some packages can't read a TIFF file with GeoTIFF info. If this occurs, the NOGEOTIFF attribute can be added to avoid GeoTIFF information.

 option = "NOGEOTIFF"          | Uncompressed without GeoTIFF
 option = "PACKBITS NOGEOTIFF" | PACKBITS without GeoTIFF info

PCI would like to thank Sam Leffler and SGI for providing the "libtiff" TIFF library, on which all of PCI's TIFF support is based. PCI would also like to thank Niles D. Ritter of the USGS who wrote the libgeotiff library on which PCI's GeoTIFF support is based.

A libtiff based suite of public domain Unix tools for dealing with TIFF files is available by anonymous ftp from www.libtiff.org on the Internet. These tools include functions to compress and uncompress TIFF files using most known TIFF compression schemes.


UK National Transfer Format (.NTF)

The GeoGateway library supports, for import, most NTF 2.0 format files provided by the Ordnance Survey in the United Kingdom. All Ordnance Survey data provided in 1994 and thereafter will be in NTF 2.0 format. Earlier formats are not guaranteed to work.

The Land-Line, Oscar, 1:625000 Topographic, 1:250000 Topographic, 1:50000 Contour and 1:50000 DTM, and 1:10000 Profile DTM products are supported; however, some structures may be lost with some of these formats. Boundary-Line files are not supported. All of these formats are vector, with the exception of the DTM files which are raster height fields constructed from contour information.

There are a variety of attributes that can be extracted with vector data; however, there is only one Attribute field per structure in the PCIDSK vector segment. To get around this limitation, NTF files are represented as having two segments. Each contains the same vectors, but with different attributes. Segment 1 of an NTF vector file will contain vectors with the feature code number as the attribute. The second segment will contain vectors with the value as the attribute.

Coordinate referencing system

All georeferenced information for NTF files is in the UK's National Grid projection, which is a type of Transverse Mercator. The GeoGateway library will represent vector and raster data with the appropriate TM projection characteristics:

  • Reference Longitude: 49.0
  • Reference Latitude: 2.0
  • False Easting: 400000
  • False Northing: -100000
  • Scale: 0.9996012717
  • Ellipsoid: Airy 1830 (E009)

There is no support for updating, or writing NTF files, nor can the DTM files be LINKed to.


UNIDSK-VMS

UNIDSK-VMS image files are partially supported by the GeoGateway library. UNIDSK-VMS is a file format used primarily by the Canada Centre for Remote Sensing (CCRS) and related facilities. It is related to the original PCI UNIDSK format, which was replaced by PCIDSK several years ago.

UNIDSK-VMS is supported for read and update access, but new UNIDSK-VMS files cannot be created. No georeferencing, nor auxiliary information is extracted from UNIDSK-VMS files.

Only 8-bit BIL, 16-bit BIL, 8-bit BSQ, and 16-bit BSQ UNIDSK-VMS files are currently supported (only 8-bit BIL has been tested). There are no PACE programs specifically for reading or writing UNIDSK-VMS files, but the LINK program does support this format.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

UVMAP (Urban Vector Map)

See VRF.


VICAR

VICAR format can be read by the GeoGateway library. VICAR format is used for AVIRIS data (Airborne Visible/Infrared Imaging Spectrometer).

Writing or updating VICAR format is not supported by the GeoGateway library.


Vision* GINA (.gia)

The GINA ASCII vector format can be read by the GeoGateway library. This format is the interchange format of the Vision* GIS software. Only versions 2.6, and 2.7 can be read.

GINA format can contain many types of data with a variety of organisations. The following aspects are not supported:

  • projections definition ... layers are treated as METRE or LAT/LONG coordinates.
  • polygon topology information is ignored.
  • network connectivity is ignored.
  • indirect tables are ignored
  • label information for features is ignored.
  • graphic overrides for features are ignored.
  • flow direction for features is ignored.

However, the following items are read:

  • All features
  • For each feature the feature class is read into a string attribute call FClass.
  • For each feature the layer number is read into an integer attribute called Layer.
  • For each feature the network number is read into an integer attribute called Network. No other networking information is preserved.
  • For each feature the feature type is read into a string attribute named FType which may have a value of "p" (polygon), "n" (node), "l" (line) or "pt" (point).
  • All the feature attributes are read as additional attributes.

The GINA file will be represented as having one layer for all features not associated with a table, and one additional layer for each table defined in the udb-primary section which actually has associated features. Due to the way in which attributes are represented through GeoGateway we segregate features into layers based on their attribute scheme rather than the GINA layer number, or feature information.


VISTA Image (.image)

The image format for the VISTA software (from the company once known as International Imaging Systems, or "I squared S") is supported by Geogateway for read only access. VISTA image files normally have the extension .image. The International Imaging Systems PRISM software also uses this same format.

Only the 8-bit unsigned, 16-bit unsigned, and 32-bit real image data types are supported. VISTA auxiliary files with graphics (vectors), LUTs, GCPs and other information are not supported at all.

An attempt is made to read the projection definition from the image file. VISTA files can have zero or more user coordinate systems (UCSes). GeoGateway will only read the first, and ignore the rest. The UCS generally has a user supplied name, but there is no easy way to relate this to a world projection, so all UCSes are treated as plain metres, and the names are discarded.

Because VISTA files employ a tiled organization, it is not possible to establish a raw format link to them.

An unusual feature of the VISTA file translator, it the ability to create PCI binary segments on them, for writing satellite models into.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

VITD (Vector Intermin Terrain Data)

See VRF.


Locate in TOC | Prev | Next Parent Topic: Supported File Formats

VMAP (Vector Smart Map)

See VRF.


VRF (Vector Relational Format)

VRF (Vector Relational Format) or VPF (Vector Product Format) is a part of the DIGEST standard. The VMAP (Vector Smart Map) format is a subset of this standard. It is supported for read only in GeoGateway. VMap Level 0 (VMAP0), Level 1 (VMAP1) and Level 2 (VMAP2) are supported. The VMap dataset can be selected in the browser by either picking the cat file in the dataset, or the directory containing the cat file can be selected with the directory browser.

VITD (Vector Intermin Terrain Data) and UVMAP (Urban Vector Map) are also supported as subsets of VRF. The dataset is selected in the same manner as VMAP.

The VRF format is supported using OGDI.


WorldMap

WorldMap is an image format originating in the former Soviet Union. Data is distributed in the United States by JEBCO. The example files provided by JEBCO are 1 band, and the assumption is that all WorldMap files are 1 band.

WorldMap files are supported for reading and updating imagery. It is also possible to LINK to WorldMap files. No georeferencing or other auxiliary information is supported for WorldMap files. It is also not possible to create WorldMap files.

WorldMap scenes consist of a number of related files, including a header file which must have the extension .rh, and the raw imagery file which must have an extension of .bsq or .bsf.w. Any of these three files may be selected to access the WorldMap image.


xBase .dbf (DBF)

xBase is a database (attribute table) format supported by many PC applications, and is a standardized form of the DBase IV file format. It is supported for import and export by the GeoGateway library, and is treated as a single vector layer with no vertices.

xBase files have no concept of a georeferencing system, and the produced attribute layer will be marked as being in the METRE georeferencing system.

xBase files are written from a vector layer, but ignore any vertex, or georeferencing information, writing only the attribute information.

All attribute types except CountedInt are supported for write in xBase files; however, all fields are assign a maximum width when written based on the field formatting information. This means there is an upper limit on the size of string that can be written to a .dbf file, though this limit is established according to the field format width in the source layer.

Only one vector layer can be written to a .dbf file, and no other datatypes can be written.

Export of xBase files is supported. xBase files are exported with a type of "DBF".

See Also


X Window Bitmap (XBM)

XBM bitmap files are supported for reading and writing by the GeoGateway library. In particular, GeoGateway supports the reading of both the X10 and X11 XBM formats, but only supports the writing of the X11 XBM format.

XBM is a 1-bit deep bitmap format. XBM files are text files which look like C code. They are often used to store user interface icon images in the X Window system.

Export of X Window Bitmap files is supported. These files are exported with a type of "XBM".

No georeferencing or other auxiliary information is exported.


X Window Dump (XWD)

Pseudocoloured, greyscale, and RGB X Window dump files are supported by the GeoGateway library. This is a format generated by the widely available xwd program, which is available on many Unix workstations, for capturing screen dumps.

X Window Dump files will have one or three image channels, and may contain a PCT or three LUTs, depending on the configuration. X Window dump files do not contain any georeferencing information, nor do they contain any fields describing the data. X Window Dump files can be created using the "New" menu selection in Works programs.

Export of X Window Dump files is supported. These files are exported with a type of "XWD".

The file must have either one, or three channels. The creation option value of "NOLUT" may be used to suppress the generation of LUT segments (for 3 channel files), or a PCT segment (for 1 channel files). Georeferencing and metadata are saved in an .aux file, but this will only be used by other PCI applications.